Re: IPv6 connectivity to mx[1-4].smtp.goog.

[Christopher Morrow]

On Tue, Feb 27, 2024 at 12:03 PM 푀풶퓇풸표 풟풶퓋풾풹퓈 via NANOG
 wrote:
>
> Op 27-02-24 om 16:22 schreef Brotman, Alex:
>
> > We are seeing the same,
>
> Thanks.
>
> > You may also want to ask the mailop list.
>
>
> I was about to do that, when I noticed that the problem seems solved.

sorry about the noise.

Re: IPv6 connectivity to mx[1-4].smtp.goog.

[푀풶퓇풸표 풟풶퓋풾풹퓈 via NANOG]

Op 27-02-24 om 16:22 schreef Brotman, Alex:


We are seeing the same,


Thanks.


You may also want to ask the mailop list.



I was about to do that, when I noticed that the problem seems solved.

--
푀풶퓇풸표

RE: IPv6 connectivity to mx[1-4].smtp.goog.

[Brotman, Alex via NANOG]

We are seeing the same, but seems like it's mostly affecting delivery for 
broadcom.com, and a few other smaller domains.  However, connectivity to the MX 
listed by gmail.com (and most other domains using GSuite, etc) are working fine 
over IPv6.

You may also want to ask the mailop list.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
 

> -Original Message-
> From: NANOG 
> On Behalf Of Marco Davids (Private) via NANOG
> Sent: Tuesday, February 27, 2024 8:03 AM
> To: nanog@nanog.org
> Subject: IPv6 connectivity to mx[1-4].smtp.goog.
> 
> Hi,
> 
> At
> https://urldefense.com/v3/__https://internet.nl__;!!CQl3mcHX2A!Dc9AZo4F
> nrpVmuo3Ehg5iQUAd4uTAsCdz9MWYKJqFWyWK7_XnaDnWN3_DkOAVq2e5
> CXVOb2triASeebvdg$  we're seeing IPv6 connection issues on TCP port
> 25 (SMTP) to mx[1-4].smtp.goog.
> 
> Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection.
> 
> Further testing seems to confirm the problem is bigger and on Google's side.
> 
> So, this fails:
> 
> echo 'quit' | nc -6 -w 3 mx1.smtp.goog. 25
> 
> and this works:
> 
> echo 'quit' | nc -4 -w 3 mx1.smtp.goog. 25
> 
> (on MacOS use -G instead of -w)
> 
> Is anyone else seeing this? Any idea what is causing this?
> 
> --
> Marco

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

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

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

[Matthew Walster via NANOG]

On Sun, 18 Feb 2024, 05:29 Owen DeLong via NANOG,  wrote:

> Most firewalls are default deny. Routers are default allow unless you put
> a filter on the interface.
>

This is not relevant though. NAT when doing port overloading, as is the
case for most CPE, is not default-deny or default-allow. The OS processes
the packet just like normal and sends an ICMP back unless there is another
firewall that says drop. NAPT adds temporary rewrite rules for each flow
that goes outbound.

NAT adds nothing to security (Bill and I agree to disagree on this), but at
> best, it complicates the audit trail.
>

It absolutely does add something. Whether that something is valuable or not
depends on your vantage point, and I'd say it's better than nothing, but
there are better solutions available.

M

>

Re: IPv6 uptake

[John Levine]

It appears that Nick Hilliard  said:
>full control of all modems and they're all relatively recent, properly 
>supported units, fully managed by the cable operator. If you start 
>adding poor quality cheap units into the mix, it can cause service problems.

The cablecos I've dealt with have a list of modems they let you use.
Since you have to give them the modem's serial number so they can
provision it from the head end, they can enforce it. Here's Spectrum's
and Comcast's list:

https://www.spectrum.net/support/internet/compliant-modems-charter-network

https://www.xfinity.com/support/devices/

>Cable modem rent is a political issue.

That too, but if you're somewhat technically competent, your own modem
and router is generally a better deal even if you have to replace the
modem every few years. You can get reasonable modems for $100 on eBay
or at big box closeouts, $150 to $200 otherwise.

Re: IPv6 uptake

[Nick Hilliard]

Michael Thomas wrote on 18/02/2024 21:18:
So it has its own wireless? I seem to recall that there were some 
economic reasons to use their CPE as little as possible to avoid rent. 
Has that changed? Or can I run down and just buy a Cablelabs certified 
router/modem these days?


There's no short answer to this question. A third party cable modem will 
work with a basic CM config file if you can convince the cable operator 
to provision the device, but cable operators don't like running third 
party kit on their network for a lot of reasons. One of these reasons is 
bandwidth channel utilisation. Another is support. Another would be 
software upgrades, which can lead to issues with security. Also, if you 
use a vanilla cable modem config, you miss out on many of the more 
interesting configurable bits on cable modems.


The root issue here is that cable networks are shared resources, and the 
cable modem polices the customers' bandwidth utilisation on instruction 
from the CMTS (head-end cable router) and the provisioning system. The 
system works well from a technical perspective when the operator has 
full control of all modems and they're all relatively recent, properly 
supported units, fully managed by the cable operator. If you start 
adding poor quality cheap units into the mix, it can cause service problems.


For example, some cable modems provide basic spectrum analysers on the 
provider interface (yes, cable operators can remotely log in to cable 
modems) and good quality reporting about RF noise. If you get some 
hobbyist demanding to use their own modem, and then you run into an RF 
problem at their premises which could normally be diagnosed remotely 
using the internal cable modem diagnostics, but you can't do this 
because the customer has used their own kit which doesn't support this, 
then you've instantly driven up your cost of service because now you 
need to schedule a call-out for something which could previously have 
been diagnosed remotely. So you can see why this might be frustrating 
for the cable modem operator.


Cable modem rent is a political issue.

Nick

Re: IPv6 uptake

[Michael Thomas]

On 2/18/24 1:10 PM, Nick Hilliard wrote:

Michael Thomas wrote on 18/02/2024 20:56:
That's really great to hear. Of course there is still the problem 
with CPE that doesn't speak v6, but that's not their fault and gives 
some reason to use their CPE.


Already solved: cable modem ipv6 support is usually also excellent, 
both in terms of subscriber services handoff and management. The 
requirements for ipv6 support are very clearly defined in the 
cablelabs docsis 3.0 specification.


So it has its own wireless? I seem to recall that there were some 
economic reasons to use their CPE as little as possible to avoid rent. 
Has that changed? Or can I run down and just buy a Cablelabs certified 
router/modem these days?


Mike

Re: IPv6 uptake

[Nick Hilliard]

Michael Thomas wrote on 18/02/2024 20:56:
That's really great to hear. Of course there is still the problem with 
CPE that doesn't speak v6, but that's not their fault and gives some 
reason to use their CPE.


Already solved: cable modem ipv6 support is usually also excellent, both 
in terms of subscriber services handoff and management. The requirements 
for ipv6 support are very clearly defined in the cablelabs docsis 3.0 
specification.


Nick

Re: IPv6 uptake

[Michael Thomas]

On 2/18/24 12:50 PM, Nick Hilliard wrote:

Michael Thomas wrote on 18/02/2024 20:28:
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,


availability of provider-side ipv6 support is generally excellent on 
docsis networks. This includes end-user device support, management, 
client and server side provisioning, the works. This is one of the 
real ipv6 success stories in the service provider arena.


That's really great to hear. Of course there is still the problem with 
CPE that doesn't speak v6, but that's not their fault and gives some 
reason to use their CPE.


Mike

Re: IPv6 uptake

[Nick Hilliard]

Michael Thomas wrote on 18/02/2024 20:28:
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,


availability of provider-side ipv6 support is generally excellent on 
docsis networks. This includes end-user device support, management, 
client and server side provisioning, the works. This is one of the real 
ipv6 success stories in the service provider arena.


Nick

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

[Michael Thomas]

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

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

[Michael Thomas]

On 2/17/24 11:27 AM, William Herrin wrote:

On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas  wrote:

I didn't hear about NAT until the
late 90's, iirc. I've definitely not heard of Gauntlet.

Then there are gaps in your knowledge.


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.

I see that the book was published in 1994. In 1994 Gauntlet was
calling their process "transparent application layer gateways," not
NAT.

What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped
to exactly one IP in both directions. Stateless 1:1 NAT had no impact
on security. But that's not the technology we're talking about in
2024. Stateless 1:1 NAT is so obsolete that support was dropped from
the Linux kernel a long time ago. That actually caused a problem for
me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off
connection tracking so that I could do asymmetric routing through the
stateless translators. No go.

So it does not surprise me that a 1994 book on network security would
not have discussed NAT. They'd have referred to the comparable
contemporary technology, which was "transparent application layer
gateways." Those behaved like what we now call NAT but did the job a
different way: instead of modifying packets, they terminated the
connection and proxied it.


I don't recall the book talking about proxies, but it's been a long 
time. It was mostly about (stateful) firewalls, iirc. The rapid 
expansion of the internet caused a huge need for a big band-aid, 
especially with shitty windows boxes emerging on the net shortly after. 
A stateful firewall walled off for incoming on client subnets was 
perfectly sufficient though, and need to provision clients with proxies 
and the necessary software. The book is not very long and honestly 
that's a feature as it seemed to mostly be trying to get the word out 
that we should be protecting ourselves at the borders until better 
security could get deployed. If NAT's supposed belt and suspenders 
security was such a big feature, I don't recall anybody talking about it 
that way back then. That's why it's always seemed like a post-hoc 
rationalization. When I was at Cisco, all of the internal networks were 
numbered in public address space and I never once heard any clamor for 
the client space to be renumbered into RFC 1918 space for security 
reasons. Admittedly anybody doing so would have faced fierce resistance, 
but if there were any debate at all it was that adding state to network 
flows was a Bad Thing.


NAT has always been about overloading public IP addresses first and 
foremost. The supposed security gains are vastly dwarfed by the decrease 
in functionality that NAT brings with it. One only has to look at the 
mental gymnastics that goes into filling out SDP announcements for VoIP 
to know that any supposed security benefits are not worth the trouble 
that it brings. If it were only security, nobody would have done it. It 
was always about address conservation first and foremost.


Mike

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

[Greg Skinner via NANOG]

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]

—gregbo

[1] https://www.wilyhacker.com
[2] https://mailarchive.ietf.org/arch/browse/big-internet/

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

[Steven Sommars]

Concerning the firewall book.

Firewalls and Internet Security, Second Edition
PDF online at
https://www.wilyhacker.com/fw2e.pdf
"Some people think that NAT boxes are a form of
firewall. In some sense, they are, but they're low-end ones."

Re: IPv6 uptake

[Stephen Satchell]

On 2/17/24 10:22 AM, Justin Streiner wrote:

Getting back to the recently revised topic of this thread - IPv6 uptake -
what have peoples' experiences been related to crafting sane v6 firewall
rulesets in recent products from the major firewall players (Palo Alto,
Cisco, Fortinet, etc)?  On the last major v6 deployment I did, working with
the firewalls was definitely one of the major pain points because the
support / stability was really lacking, or there wasn't full feature parity
between their v4 and v6 capabilities.


Depends on how complex you want to be with firewall rules.

My web server is on Ubuntu 20.04.  During the IPv4-only days, I used UFW 
(uncomplicated firewall) to implement a mostly-closed firewall, punching 
pin-holes for 80 and 443, and disable any interface forwarding.  When I 
upgraded to IPv4 and IPv6, the process of duplicating the policy in IPv6 
was easy.


The UFW package is built on top of IPTABLES and IP6TABLES.

Now, my edge router is going to be a different story.  As the number of 
rules goes up, UFW becomes tedious and finicky. Manually crafting rules 
in NFT is tedious and error-prone.  Getting all the rules right the 
first time is, um, hard.  Automation is absolutely required.  So I'm 
writing the automation in Python, and driving the rules generator from a 
YAML database.


Expect this to be published on Github.  When?  Depends on when I find 
the time.  This is not a priority project -- I'm so mad at my upstream 
that I find playing Mahjongg is necessary to settle my nerves.


I've said this earlier: by the time the NEED for IPv6 arises, I expect 
to be dead.

Re: IPv6 mail The Reg does 240/4

[Michael Thomas]

On 2/17/24 2:21 PM, John Levine wrote:

But what happens under the hood at

major mailbox providers is maddeningly opaque so who really knows? It
would be nice if MAAWG published a best practices or something like that
to outline what is actually happening in live deployments.

Unfortunately, spammers can read just as well as we can so it's not
going to happen.


They already have the recon so they don't need any help. The rest of us 
could be helped by what the current art is.


Mike

Re: IPv6 mail The Reg does 240/4

[John Levine]

It appears that Michael Thomas  said:
>I kind of get the impression that once you get to aggregates at the 
>domain level like DKIM or SPF, addresses as a reputation vehicle don't 
>much figure into decision making.

It definitely does, since there are plenty of IPs that send only
malicious mail, or that shouldn't be sending mail at all. Every large
mail system uses Spamhaus' IP lists as part of their filtering
process. 

I hear that SPF is largely useless these days because most SPF records
include IP ranges for many mail providers, and a lot of those
providers do a poor job of keeping one customer from spoofing mail
from another. DKIM is still quite useful.

K. But what happens under the hood at 
>major mailbox providers is maddeningly opaque so who really knows? It 
>would be nice if MAAWG published a best practices or something like that 
>to outline what is actually happening in live deployments.

Unfortunately, spammers can read just as well as we can so it's not
going to happen.

R's,
John

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

[Brandon Butterworth]

On 17/02/2024, 19:27:20, "William Herrin"  wrote:

So it does not surprise me that a 1994 book on network security would
not have discussed NAT. They'd have referred to the comparable
contemporary technology, which was "transparent application layer
gateways." Those behaved like what we now call NAT but did the job a
different way: instead of modifying packets, they terminated the
connection and proxied it.


And that was a very desired feature plus the address isolation,
then and for decades since. The clients IP stack was not trusted
to interact directly with external hosts.

See socks proxy too (and later Squid). It is still in use today
in some places.

There were stateful firewalls but trust was reduced when the
Firewall 1 undocumented and not unconfigurable default DNS UDP
inbound rule was discovered, it let anyone on the Internets "DNS"
packets reach any host on the inside they could guess the address
of. The "what if the product does allow packets in it is expected
not to" consideration drove having unreachable internal addressing.

Clicking on rules and assuming it is all good forever more through
product revisions was not sufficient. Every version would need a
significant re audit and probably miss any real problem.

How are people validating their firewall does what they think it
does?

brandon

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

[William Herrin]

On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas  wrote:
> I didn't hear about NAT until the
> late 90's, iirc. I've definitely not heard of Gauntlet.

Then there are gaps in your knowledge.

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

I see that the book was published in 1994. In 1994 Gauntlet was
calling their process "transparent application layer gateways," not
NAT.

What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped
to exactly one IP in both directions. Stateless 1:1 NAT had no impact
on security. But that's not the technology we're talking about in
2024. Stateless 1:1 NAT is so obsolete that support was dropped from
the Linux kernel a long time ago. That actually caused a problem for
me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off
connection tracking so that I could do asymmetric routing through the
stateless translators. No go.

So it does not surprise me that a 1994 book on network security would
not have discussed NAT. They'd have referred to the comparable
contemporary technology, which was "transparent application layer
gateways." Those behaved like what we now call NAT but did the job a
different way: instead of modifying packets, they terminated the
connection and proxied it.

Regards,
Bill Herrin


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

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

[William Herrin]

On Sat, Feb 17, 2024 at 10:22 AM Justin Streiner  wrote:
> Getting back to the recently revised topic of this thread - IPv6
> uptake - what have peoples' experiences been related to
> crafting sane v6 firewall rulesets in recent products from the
> major firewall players (Palo Alto, Cisco, Fortinet, etc)?

Hi Justin,

It's been years since I used anything other than Linux to build
someone a firewall. It has such a superior toolset, not just for
setting rules but for diagnosing things that don't work as expected.
The COTS products aren't just painful for IPv6, they're painful for
IPv4.

I especially despised the Cisco PIX/ASA line. I did use Fortinet's WAF
product for a while and it was okay. I only used it as a reverse proxy
to a web server, and then only because it was a security compliance
requirement for that project.

Regards,
Bill Herrin



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

Re: IPv6 uptake

[Michael Thomas]

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)

[Owen DeLong via NANOG]

I can’t speak to Cisco as I don’t have recent experience there. Juniper, Linux, Palo Alto, and most others I’ve dealt with in the last 5 years pose no significant difference in writing policy for IPv6 vs. the process for IPv4. OwenOn Feb 17, 2024, at 10:23, Justin Streiner  wrote:We went pretty deep into the weeds on NAT in this thread - far deeper than I expected ;)Getting back to the recently revised topic of this thread - IPv6 uptake - what have peoples' experiences been related to crafting sane v6 firewall rulesets in recent products from the major firewall players (Palo Alto, Cisco, Fortinet, etc)?  On the last major v6 deployment I did, working with the firewalls was definitely one of the major pain points because the support / stability was really lacking, or there wasn't full feature parity between their v4 and v6 capabilities.Thank youjmsOn Fri, Feb 16, 2024 at 11:04 PM William Herrin  wrote:On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > That it's possible to implement network security well without using
> > NAT does not contradict the claim that NAT enhances network security.
>
> I think we're each overgeneralizing from our individual expeience.
>
> You can configure a V6 firewall to be default closed as easily as you can
> configure a NAT.

Hi John,

We're probably not speaking the same language. You're talking about
configuring the function of one layer in a security stack. I'm talking
about adding or removing a layer in a security stack. Address
overloaded NAT in conjunction with private internal addresses is an
additional layer in a security stack. It has security-relevant
properties that the other layers don't duplicate. Regardless of how
you configure it.

Also, you can't "configure" a layer to be default closed. That's a
property of the security layer. It either is or it is not.

You can configure a layer to be "default deny," which I assume is what
you meant. The issue is that anything that can be configured can be
accidentally unconfigured. When default-deny is accidentally
unconfigured, the network becomes wide open. When NAT is accidentally
unconfigured, the network stops functioning entirely. The gate is
closed.

Regards,
Bill Herrin


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

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

[Owen DeLong via NANOG]

> Think of it like this: you have a guard, you have a fence and you have
> barbed wire on top of the fence. Can you secure the place without the
> barbed wire? Of course. Can an intruder defeat the barbed wire? Of
> course. Is it more secure -with- the barbed wire? Obviously.
> 
NAT is like the barbed wire. Anyone with a pair of wire cutters doesn’t need to 
defeat the barbed wire, they just cut the fence instead. 

But I understand how the barbed wire makes you and management feel warm and 
fuzzy. 

The problem here is that NAT is also like a big blind spot in the video cameras 
that should be helping you spot the guy cutting the fence. 

Owen

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

[Owen DeLong via NANOG]

Bill, same scenario, but instead of fat fingering an outbound rule, you fat 
finger a port map for inbound connections to a different host and get the 
destination address wrong. 

Still hacked. 

NAT doesn’t prevent fat fingers from getting you hacked, it just changes the 
nature of the required fat fingering. 

Care to talk about trying to track down a compromised host through the audit 
trail given an abuse report that doesn’t include the source port number? 
(Oracle even one that happens to include it)?

Owen


> On Feb 16, 2024, at 17:05, William Herrin  wrote:
> 
> On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:
>> If you know which subnets need to be NAT'd don't you also know which
>> ones shouldn't exposed to incoming connections (or conversely, which
>> should be permitted)? It seems to me that all you're doing is moving
>> around where that knowledge is stored? Ie, DHCP so it can give it
>> private address rather than at the firewall knowing which subnets not to
>> allow access? Yes, DHCP can be easily configured to make everything
>> private, but DHCP for static reachable addresses is pretty handy too.
> 
> Hi Mike,
> 
> Suppose I have a firewall at 2602:815:6000::1 with an internal network
> of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
> switch that accepts telnet connections with a user/password of
> admin/admin. On the firewall, I program it to disallow all Internet
> packets to 2602:815:6001::/64 that are not part of an established
> connection.
> 
> Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
> 
> Now, I make a mistake on my firewall. I insert a rule intended to
> allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> so it allows them inbound to that address instead. Someone tries to
> telnet to 2602:815:6001::4. What happens? Hacked.
> 
> Now suppose I have a firewall at 199.33.225.1 with an internal network
> of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
> that accepts telnet connections with a user/password of admin/admin.
> 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.
> 
> Now I make a mistake on my firewall. I insert a rule intended to allow
> packets outbound from 192.168.55.4 but I fat-finger it and so it
> allows them inbound to that address instead. Someone tries to telnet
> to 192.168.55.4. What happens? The packet STILL doesn't reach my
> firewall because that IP address doesn't go anywhere on the Internet.
> 
> See the difference? Accessible versus accessible and addressable. Not
> addressable enhances security.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

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

[Michael Thomas]

On 2/16/24 6:33 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel  wrote:

Depending on where that rule is placed within your ACL, yes that can happen 
with *ANY* address family.

Hi Ryan,

Correct. The examples illustrated a difference between a firewall
implementing address-overloaded NAT and a firewall implementing
everything except the address translation. Either example could be
converted to the other address family and it would work the same way.


All things aside, I agree with Dan that NAT was never
ever designed to be a security tool. It is used because
of the scarcity of public address space, and it provides
a "defense" depending on how it is implemented, with
minimal effort. This video tells the story of NAT and the
Cisco PIX, straight from the creators
https://youtu.be/GLrfqtf4txw

NAT's story, the modern version of NAT when we talk about IPv4
firewalls, started in the early '90s with the Gauntlet firewall. It
was described as a transparent application layer gateway. Gauntlet
focused on solving enterprise security issues. Gauntlet's technology
converged with what was then 1:1 NAT to produce the address-overloaded
NAT like what later appeared in the Cisco PIX (also first and foremost
a security product) and is present in all our DSL and cable modems
today.

Security came first, then someone noticed it'd be useful for address
conservation too. Gauntlet's customers generally had or could readily
get a supply of public IP addresses. Indeed, when Gauntlet was
released, IP addresses were still available from
hostmas...@internic.net at zero cost and without any significant
documentation. And Gauntlet was expensive: folks who couldn't easily
obtain public IP addresses also couldn't afford it.


Funny, I don't recall Bellovin and Cheswick's Firewall book discussing 
NAT. That was sort of the go-to book for hard-on-the-outside 
soft-on-the-inside defense. Maybe they were unaware of this, or maybe 
they didn't agree with the premise. I didn't hear about NAT until the 
late 90's, iirc. I've definitely not heard of Gauntlet.


As I recall, it was very much an afterthought with cable/DOCSIS to use 
NAT to conserve addresses. The headend DHCP server just gave public 
addresses to whoever asked. DOCSIS CPE at that time was just an L2 
modem. NAT traversal absolutely was not on the table with Packetcable 
back in the late 90's, and believe me we were very concerned about the 
security of MGCP since it was UDP based.


Which is to say that NAT came around to preserve address space. Any 
security properties were sort of a post-hoc rationalization and hotly 
debated given all the things NAT broke.


Mike

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

[Owen DeLong via NANOG]

Most firewalls are default deny. Routers are default allow unless you put a 
filter on the interface.

NAT adds nothing to security (Bill and I agree to disagree on this), but at 
best, it complicates the audit trail. 

Owen


> On Feb 16, 2024, at 15:19, Jay R. Ashworth  wrote:
> 
> - Original Message -
>> From: "William Herrin" 
> 
>> On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:
 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.
>> 
>> Every firewall does that. What NAT does above and beyond is place
>> control of what internal nodes are -addressable- from the outside in
>> the hands of the people inside -- so that most of the common mistakes
>> with firewall configuration don't cause the internal hosts to -become-
>> accessible.
>> 
>> The distinction doesn't seem that subtle to me, but a lot of folks
>> making statements about network security on this list don't appear to
>> grasp it.
> 
> You bet.  I knew someone would chime in, but whether they'd be agreeing
> with me -- as you are -- or yelling at me, wasn't clear.
> 
> It's a default deny (NAT) vs default allow (firewall) question, and
> I prefer default deny -- at least inbound.  You *can* run NAT as default
> deny outbound, too, but it's much less tolerable for general internet
> connectivity -- in some dedicated circumstances, it can be workable.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

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

[Owen DeLong via NANOG]

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

Owen

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

[William Herrin]

On Sat, Feb 17, 2024 at 10:03 AM Michael Thomas  wrote:
> On 2/16/24 5:37 PM, William Herrin wrote:
> > What is there to address? I already said that NAT's security
> > enhancement comes into play when a -mistake- is made with the network
> > configuration. You want me to say it again? Okay, I've said it again.
>
> The implication being that we should keep NAT'ing ipv6 for... a thin
> veil of security. That all of the other things that NAT breaks is worth
> the trouble because we can't trust our fat fingers on firewall configs.

Hi Mike,

There's no "we" here, no one-size-fits-all answer. Some folks
evaluating their scenario with their details will conclude that NAT's
security benefit outweighs its performance and functionality
implications. Others evaluating other scenarios will reach different
answers.

For enterprise customers, you're talking about folks who've been doing
NAT for two decades and have more recently implemented HTTPS capture
and re-encryption in order to scan for malware in transit. Will many
of them insist on NAT and its security enhancement when they get
around to deploying IPv6? Bet on it.

So, what happens when you try to tell such folks that they don't need
NAT for security in IPv6? It contradicts their -correct- intuition
that NAT has a security benefit, but because they can't quite nail
down what's wrong with your claim, it leaves them unsure. And what do
people who are unsure about an IPv6 deployment do? Nothing! They put
it back on the shelf and return to it in a couple of years.

Regards,
Bill Herrin


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

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

[Justin Streiner]

We went pretty deep into the weeds on NAT in this thread - far deeper than
I expected ;)

Getting back to the recently revised topic of this thread - IPv6 uptake -
what have peoples' experiences been related to crafting sane v6 firewall
rulesets in recent products from the major firewall players (Palo Alto,
Cisco, Fortinet, etc)?  On the last major v6 deployment I did, working with
the firewalls was definitely one of the major pain points because the
support / stability was really lacking, or there wasn't full feature parity
between their v4 and v6 capabilities.

Thank you
jms

On Fri, Feb 16, 2024 at 11:04 PM William Herrin  wrote:

> On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > > That it's possible to implement network security well without using
> > > NAT does not contradict the claim that NAT enhances network security.
> >
> > I think we're each overgeneralizing from our individual expeience.
> >
> > You can configure a V6 firewall to be default closed as easily as you can
> > configure a NAT.
>
> Hi John,
>
> We're probably not speaking the same language. You're talking about
> configuring the function of one layer in a security stack. I'm talking
> about adding or removing a layer in a security stack. Address
> overloaded NAT in conjunction with private internal addresses is an
> additional layer in a security stack. It has security-relevant
> properties that the other layers don't duplicate. Regardless of how
> you configure it.
>
> Also, you can't "configure" a layer to be default closed. That's a
> property of the security layer. It either is or it is not.
>
> You can configure a layer to be "default deny," which I assume is what
> you meant. The issue is that anything that can be configured can be
> accidentally unconfigured. When default-deny is accidentally
> unconfigured, the network becomes wide open. When NAT is accidentally
> unconfigured, the network stops functioning entirely. The gate is
> closed.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

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

[Michael Thomas]

On 2/16/24 5:37 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas  wrote:

So you're not going to address that this is a management plain problem.

Hi Mike,

What is there to address? I already said that NAT's security
enhancement comes into play when a -mistake- is made with the network
configuration. You want me to say it again? Okay, I've said it again.


The implication being that we should keep NAT'ing ipv6 for... a thin 
veil of security. That all of the other things that NAT breaks is worth 
the trouble because we can't trust our fat fingers on firewall configs.


Mike

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

[Tom Beecher]

>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like this: you have a guard, you have a fence and you have
> barbed wire on top of the fence. Can you secure the place without the
> barbed wire? Of course. Can an intruder defeat the barbed wire? Of
> course. Is it more secure -with- the barbed wire? Obviously.
>

Bill-

In a security context, NAT/PAT only provides *obfuscation* of the internal
numbering and source ports of the networks on the inside of the NAT/PAT
device. "Security by obscurity" is a well debunked maxim by now. Any
perceived benefits that obscurity provides are gone as soon as the
information attempting to be hidden can be discovered, or the methods by
which it functions are known. It may slightly deter the lazy, but
techniques to discover the otherwise 'hidden' numbering and port usage have
existed for decades.


On Fri, Feb 16, 2024 at 10:28 PM William Herrin  wrote:

> On Fri, Feb 16, 2024 at 7:10 PM John Levine  wrote:
> > If you configure your firewall wrong, bad things will happen.  I have
> both
> > IPv6 and NAT IPv4 on my network here and I haven't found it particularly
> > hard to get the config correct for IPv6.
>
> Hi John,
>
> That it's possible to implement network security well without using
> NAT does not contradict the claim that NAT enhances network security.
>
> That it's possible to breach the layer of security added by NAT does
> not contradict the claim that NAT enhances network security.
>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like this: you have a guard, you have a fence and you have
> barbed wire on top of the fence. Can you secure the place without the
> barbed wire? Of course. Can an intruder defeat the barbed wire? Of
> course. Is it more secure -with- the barbed wire? Obviously.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

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

[Ryan Hamel]

Again Bill, the NAT process layer is not involved in dropping unwanted traffic 
until the packet is at least four/five levels deep. On ingress, a firewall will 
check if there is any flow/stream associated to it, ensure the packet follows 
the applicable protocol state machine, process it against the inbound interface 
rules, do any DPI rule processing, THEN NAT lookup, and egress routing + ACLs 
on the outbound ACL. 
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

On a standard LAN -> WAN firewall configured with a single public IPv4 IP; your 
protection comes from the connect state/flow tables primarily. No one would be 
touching NAT configurations at the same rate as zone and policy configurations, 
unless it's for complex VPN setups. Using NAT as a defense in depth strategy 
against deploying v6 is only hurting yourself. I have yet to come across an 
enterprise that uses it between internal VLANs or policies/zones, where the 
same threat potential can be, especially in a DMZ.

Ryan Hamel


From: NANOG  on behalf of William 
Herrin 
Sent: Friday, February 16, 2024 8:03 PM
To: John R. Levine 
Cc: nanog@nanog.org 
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > That it's possible to implement network security well without using
> > NAT does not contradict the claim that NAT enhances network security.
>
> I think we're each overgeneralizing from our individual expeience.
>
> You can configure a V6 firewall to be default closed as easily as you can
> configure a NAT.

Hi John,

We're probably not speaking the same language. You're talking about
configuring the function of one layer in a security stack. I'm talking
about adding or removing a layer in a security stack. Address
overloaded NAT in conjunction with private internal addresses is an
additional layer in a security stack. It has security-relevant
properties that the other layers don't duplicate. Regardless of how
you configure it.

Also, you can't "configure" a layer to be default closed. That's a
property of the security layer. It either is or it is not.

You can configure a layer to be "default deny," which I assume is what
you meant. The issue is that anything that can be configured can be
accidentally unconfigured. When default-deny is accidentally
unconfigured, the network becomes wide open. When NAT is accidentally
unconfigured, the network stops functioning entirely. The gate is
closed.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D=0<https://bill.herrin.us/>

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

[William Herrin]

On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > That it's possible to implement network security well without using
> > NAT does not contradict the claim that NAT enhances network security.
>
> I think we're each overgeneralizing from our individual expeience.
>
> You can configure a V6 firewall to be default closed as easily as you can
> configure a NAT.

Hi John,

We're probably not speaking the same language. You're talking about
configuring the function of one layer in a security stack. I'm talking
about adding or removing a layer in a security stack. Address
overloaded NAT in conjunction with private internal addresses is an
additional layer in a security stack. It has security-relevant
properties that the other layers don't duplicate. Regardless of how
you configure it.

Also, you can't "configure" a layer to be default closed. That's a
property of the security layer. It either is or it is not.

You can configure a layer to be "default deny," which I assume is what
you meant. The issue is that anything that can be configured can be
accidentally unconfigured. When default-deny is accidentally
unconfigured, the network becomes wide open. When NAT is accidentally
unconfigured, the network stops functioning entirely. The gate is
closed.

Regards,
Bill Herrin


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

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

[John R. Levine]

That it's possible to implement network security well without using
NAT does not contradict the claim that NAT enhances network security.


I think we're each overgeneralizing from our individual expeience.

You can configure a V6 firewall to be default closed as easily as you can 
configure a NAT.  Once you start making exceptions, it depends on the 
nature of the exceptions, the way you tell the router about them (CLI, web 
crudware, whatever) and doubtless other stuff too.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

[William Herrin]

On Fri, Feb 16, 2024 at 7:10 PM John Levine  wrote:
> If you configure your firewall wrong, bad things will happen.  I have both
> IPv6 and NAT IPv4 on my network here and I haven't found it particularly
> hard to get the config correct for IPv6.

Hi John,

That it's possible to implement network security well without using
NAT does not contradict the claim that NAT enhances network security.

That it's possible to breach the layer of security added by NAT does
not contradict the claim that NAT enhances network security.

Any given layer of security can be breached with expense and effort.
Breaching every layer of security at the same time is more challenging
than breaching any particular one of them. The use of NAT adds a layer
of security to the system that is not otherwise there.


Think of it like this: you have a guard, you have a fence and you have
barbed wire on top of the fence. Can you secure the place without the
barbed wire? Of course. Can an intruder defeat the barbed wire? Of
course. Is it more secure -with- the barbed wire? Obviously.

Regards,
Bill Herrin

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

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

[John Levine]

It appears that William Herrin  said:
>Now suppose I have a firewall at 199.33.225.1 with an internal network
>of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
>that accepts telnet connections with a user/password of admin/admin.
>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.

Or you set up port forwarding for some other device but you mistype the
internal address an forward it to the switch.  Or the switch helpfully
uses UPNP to do its own port forwarding and you forget to turn it off.

If you configure your firewall wrong, bad things will happen.  I have both
IPv6 and NAT IPv4 on my network here and I haven't found it particularly
hard to get the config correct for IPv6.

Normally the ISP will give you an IPv6 /56 or larger so you can have
multiple segments behind the router each with a /64 and different
policies for each segment.

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

[William Herrin]

On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel  wrote:
> Depending on where that rule is placed within your ACL, yes that can happen 
> with *ANY* address family.

Hi Ryan,

Correct. The examples illustrated a difference between a firewall
implementing address-overloaded NAT and a firewall implementing
everything except the address translation. Either example could be
converted to the other address family and it would work the same way.

> All things aside, I agree with Dan that NAT was never
> ever designed to be a security tool. It is used because
> of the scarcity of public address space, and it provides
> a "defense" depending on how it is implemented, with
> minimal effort. This video tells the story of NAT and the
> Cisco PIX, straight from the creators
> https://youtu.be/GLrfqtf4txw

NAT's story, the modern version of NAT when we talk about IPv4
firewalls, started in the early '90s with the Gauntlet firewall. It
was described as a transparent application layer gateway. Gauntlet
focused on solving enterprise security issues. Gauntlet's technology
converged with what was then 1:1 NAT to produce the address-overloaded
NAT like what later appeared in the Cisco PIX (also first and foremost
a security product) and is present in all our DSL and cable modems
today.

Security came first, then someone noticed it'd be useful for address
conservation too. Gauntlet's customers generally had or could readily
get a supply of public IP addresses. Indeed, when Gauntlet was
released, IP addresses were still available from
hostmas...@internic.net at zero cost and without any significant
documentation. And Gauntlet was expensive: folks who couldn't easily
obtain public IP addresses also couldn't afford it.

Regards,
Bill Herrin

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

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

[Ryan Hamel]

sronan,

A subnet can come from the ISP (residential/small business), or business is 
utilizing BGP with their upstream. When V6 is in use, a firewall does not need 
to perform NAT, just stateful flow inspection and applying the applicable rules 
based on the zone and/or interface.

Bill,

Depending on where that rule is placed within your ACL, yes that can happen 
with *ANY* address family.

---

All things aside, I agree with Dan that NAT was never ever designed to be a 
security tool. It is used because of the scarcity of public address space, and 
it provides a "defense" depending on how it is implemented, with minimal 
effort. This video tells the story of NAT and the Cisco PIX, straight from the 
creators https://youtu.be/GLrfqtf4txw

Ryan Hamel


From: NANOG  on behalf of 
sro...@ronan-online.com 
Sent: Friday, February 16, 2024 5:44 PM
To: William Herrin 
Cc: nanog@nanog.org 
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


Why is your Internal v6 subnet advertised to the Internet?

> On Feb 16, 2024, at 8:08 PM, William Herrin  wrote:
>
> On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:
>> If you know which subnets need to be NAT'd don't you also know which
>> ones shouldn't exposed to incoming connections (or conversely, which
>> should be permitted)? It seems to me that all you're doing is moving
>> around where that knowledge is stored? Ie, DHCP so it can give it
>> private address rather than at the firewall knowing which subnets not to
>> allow access? Yes, DHCP can be easily configured to make everything
>> private, but DHCP for static reachable addresses is pretty handy too.
>
> Hi Mike,
>
> Suppose I have a firewall at 2602:815:6000::1 with an internal network
> of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
> switch that accepts telnet connections with a user/password of
> admin/admin. On the firewall, I program it to disallow all Internet
> packets to 2602:815:6001::/64 that are not part of an established
> connection.
>
> Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
>
> Now, I make a mistake on my firewall. I insert a rule intended to
> allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> so it allows them inbound to that address instead. Someone tries to
> telnet to 2602:815:6001::4. What happens? Hacked.
>
> Now suppose I have a firewall at 199.33.225.1 with an internal network
> of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
> that accepts telnet connections with a user/password of admin/admin.
> 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.
>
> Now I make a mistake on my firewall. I insert a rule intended to allow
> packets outbound from 192.168.55.4 but I fat-finger it and so it
> allows them inbound to that address instead. Someone tries to telnet
> to 192.168.55.4. What happens? The packet STILL doesn't reach my
> firewall because that IP address doesn't go anywhere on the Internet.
>
> See the difference? Accessible versus accessible and addressable. Not
> addressable enhances security.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C5672986956c34e345fd208dc2f5a571c%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437312255883842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=iuKWxWts%2B9buTCz318C7hz6DbuWSST%2FKPZAWbbhSj8Q%3D=0<https://bill.herrin.us/>

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

[William Herrin]

On Fri, Feb 16, 2024 at 5:45 PM  wrote:
> Why is your Internal v6 subnet advertised to the Internet?

Because that was the example network -without- NAT. If I made two
networks -with- NAT, there would be no difference to show.

I make 2602:815:6000::/44 be 199.33.224.0/23, make 2602:815:6001::/64
be 199.33.224.0/24, make 2602:815:600::1 be 199.33.225.1 and make
2602:815:6001::4 be 199.33.224.4, it would be the exact same example
with the exact same network security impact.

Regards,
Bill Herrin


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

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

[sronan]

Why is your Internal v6 subnet advertised to the Internet?

> On Feb 16, 2024, at 8:08 PM, William Herrin  wrote:
> 
> On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:
>> If you know which subnets need to be NAT'd don't you also know which
>> ones shouldn't exposed to incoming connections (or conversely, which
>> should be permitted)? It seems to me that all you're doing is moving
>> around where that knowledge is stored? Ie, DHCP so it can give it
>> private address rather than at the firewall knowing which subnets not to
>> allow access? Yes, DHCP can be easily configured to make everything
>> private, but DHCP for static reachable addresses is pretty handy too.
> 
> Hi Mike,
> 
> Suppose I have a firewall at 2602:815:6000::1 with an internal network
> of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
> switch that accepts telnet connections with a user/password of
> admin/admin. On the firewall, I program it to disallow all Internet
> packets to 2602:815:6001::/64 that are not part of an established
> connection.
> 
> Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
> 
> Now, I make a mistake on my firewall. I insert a rule intended to
> allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> so it allows them inbound to that address instead. Someone tries to
> telnet to 2602:815:6001::4. What happens? Hacked.
> 
> Now suppose I have a firewall at 199.33.225.1 with an internal network
> of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
> that accepts telnet connections with a user/password of admin/admin.
> 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.
> 
> Now I make a mistake on my firewall. I insert a rule intended to allow
> packets outbound from 192.168.55.4 but I fat-finger it and so it
> allows them inbound to that address instead. Someone tries to telnet
> to 192.168.55.4. What happens? The packet STILL doesn't reach my
> firewall because that IP address doesn't go anywhere on the Internet.
> 
> See the difference? Accessible versus accessible and addressable. Not
> addressable enhances security.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

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

[William Herrin]

On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas  wrote:
> So you're not going to address that this is a management plain problem.

Hi Mike,

What is there to address? I already said that NAT's security
enhancement comes into play when a -mistake- is made with the network
configuration. You want me to say it again? Okay, I've said it again.

Regards,
Bill Herrin

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

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

[Michael Thomas]

On 2/16/24 5:30 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas  wrote:

On 2/16/24 5:05 PM, William Herrin wrote:

Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.

Yes, but if the DHCP database has a mistake it's pretty much the same
situation since it could be numbered with a public address.

Um. No. You'd have to make multiple mistakes cross-contaminating your
public and private ethernet segments yet somehow without completely
breaking your network rendering it inoperable.


So you're not going to address that this is a management plain problem. ok.

Mike

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

[William Herrin]

On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas  wrote:
> On 2/16/24 5:05 PM, William Herrin wrote:
> > Now, I make a mistake on my firewall. I insert a rule intended to
> > allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> > so it allows them inbound to that address instead. Someone tries to
> > telnet to 2602:815:6001::4. What happens? Hacked.
>
> Yes, but if the DHCP database has a mistake it's pretty much the same
> situation since it could be numbered with a public address.

Um. No. You'd have to make multiple mistakes cross-contaminating your
public and private ethernet segments yet somehow without completely
breaking your network rendering it inoperable.


> NAT is not without its own set of problems,

NAT's problems are legion. But the question was whether and how NAT
improves the security of a network employing it.

Regards,
Bill Herrin


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

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

[Michael Thomas]

On 2/16/24 5:05 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:

If you know which subnets need to be NAT'd don't you also know which
ones shouldn't exposed to incoming connections (or conversely, which
should be permitted)? It seems to me that all you're doing is moving
around where that knowledge is stored? Ie, DHCP so it can give it
private address rather than at the firewall knowing which subnets not to
allow access? Yes, DHCP can be easily configured to make everything
private, but DHCP for static reachable addresses is pretty handy too.

Hi Mike,

Suppose I have a firewall at 2602:815:6000::1 with an internal network
of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
switch that accepts telnet connections with a user/password of
admin/admin. On the firewall, I program it to disallow all Internet
packets to 2602:815:6001::/64 that are not part of an established
connection.

Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.

Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.


Yes, but if the DHCP database has a mistake it's pretty much the same 
situation since it could be numbered with a public address. For both you 
can have the default as "reject" or "accept" -- that's just a default 
and depends on how you want to manage your network.


NAT is not without its own set of problems, so if this boils down to a 
subnet management issue there are obviously ways to deal with that to 
avoid NAT's problems. Both DHCP and firewall configs don't have to be 
the ultimate source of truth about any of this. And that's likely a Good 
Thing since you want them to be pretty much as fungible and replaceable 
as possible. If you're exposed to fat fingers for either, you're 
probably already in trouble. Something in the management plain is far 
more likely to care about this kind of thing than hardware vendors who 
see that as a cost center with predictably shitty implementations.


Mike

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

[William Herrin]

On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:
> If you know which subnets need to be NAT'd don't you also know which
> ones shouldn't exposed to incoming connections (or conversely, which
> should be permitted)? It seems to me that all you're doing is moving
> around where that knowledge is stored? Ie, DHCP so it can give it
> private address rather than at the firewall knowing which subnets not to
> allow access? Yes, DHCP can be easily configured to make everything
> private, but DHCP for static reachable addresses is pretty handy too.

Hi Mike,

Suppose I have a firewall at 2602:815:6000::1 with an internal network
of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
switch that accepts telnet connections with a user/password of
admin/admin. On the firewall, I program it to disallow all Internet
packets to 2602:815:6001::/64 that are not part of an established
connection.

Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.

Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.

Now suppose I have a firewall at 199.33.225.1 with an internal network
of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
that accepts telnet connections with a user/password of admin/admin.
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.

Now I make a mistake on my firewall. I insert a rule intended to allow
packets outbound from 192.168.55.4 but I fat-finger it and so it
allows them inbound to that address instead. Someone tries to telnet
to 192.168.55.4. What happens? The packet STILL doesn't reach my
firewall because that IP address doesn't go anywhere on the Internet.

See the difference? Accessible versus accessible and addressable. Not
addressable enhances security.

Regards,
Bill Herrin


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

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

[Daniel Marks via NANOG]

> a lot of folks
> making statements about network security on this list don't appear to
> grasp it.

If your network is secure, it isn’t even possible to “accidentally” open 
inbound ports in the first place. You either allow it to happen or you don’t 
via security policy, anything else means your “security” relies on humans not 
making a mistake, and that’s not security.

Using NAT as a “line of defense” means you implicitly don’t trust your 
authorization system, which means you don't actually have a security posture to 
begin with.

Using the same logic, you might as well go buy another firewall to put in front 
of your actual Firewall just in case you accidentally misconfigure it. Notice 
how you’re not actually securing anything, you’re putting a band aid on your 
insecure process.

-Dan

> On Feb 16, 2024, at 18:04, William Herrin  wrote:
> 
> On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:
>>> 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.
> 
> Hi Jay,
> 
> Every firewall does that. What NAT does above and beyond is place
> control of what internal nodes are -addressable- from the outside in
> the hands of the people inside -- so that most of the common mistakes
> with firewall configuration don't cause the internal hosts to -become-
> accessible.
> 
> The distinction doesn't seem that subtle to me, but a lot of folks
> making statements about network security on this list don't appear to
> grasp it.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

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

[Jay R. Ashworth]

- Original Message -
> From: "William Herrin" 

> On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:
>> > 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.
> 
> Every firewall does that. What NAT does above and beyond is place
> control of what internal nodes are -addressable- from the outside in
> the hands of the people inside -- so that most of the common mistakes
> with firewall configuration don't cause the internal hosts to -become-
> accessible.
> 
> The distinction doesn't seem that subtle to me, but a lot of folks
> making statements about network security on this list don't appear to
> grasp it.

You bet.  I knew someone would chime in, but whether they'd be agreeing
with me -- as you are -- or yelling at me, wasn't clear.

It's a default deny (NAT) vs default allow (firewall) question, and
I prefer default deny -- at least inbound.  You *can* run NAT as default
deny outbound, too, but it's much less tolerable for general internet
connectivity -- in some dedicated circumstances, it can be workable.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

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

[Michael Thomas]

On 2/16/24 3:01 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:

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.

Hi Jay,

Every firewall does that. What NAT does above and beyond is place
control of what internal nodes are -addressable- from the outside in
the hands of the people inside -- so that most of the common mistakes
with firewall configuration don't cause the internal hosts to -become-
accessible.


If you know which subnets need to be NAT'd don't you also know which 
ones shouldn't exposed to incoming connections (or conversely, which 
should be permitted)? It seems to me that all you're doing is moving 
around where that knowledge is stored? Ie, DHCP so it can give it 
private address rather than at the firewall knowing which subnets not to 
allow access? Yes, DHCP can be easily configured to make everything 
private, but DHCP for static reachable addresses is pretty handy too.


Mike

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

[William Herrin]

On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:
> > 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.

Hi Jay,

Every firewall does that. What NAT does above and beyond is place
control of what internal nodes are -addressable- from the outside in
the hands of the people inside -- so that most of the common mistakes
with firewall configuration don't cause the internal hosts to -become-
accessible.

The distinction doesn't seem that subtle to me, but a lot of folks
making statements about network security on this list don't appear to
grasp it.

Regards,
Bill Herrin


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

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

[Jay R. Ashworth]

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

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

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

[Stephen Satchell]

On 2/15/24 9:40 PM, Justin Streiner wrote:

The Internet edge and core portion of deploying IPv6 - dual-stack or
otherwise - is fairly easy. I led efforts to do this at a large .edu
starting in 2010/11.  The biggest hurdles are/were/might still be:
1. Coming up with a good address plan that will do what you want and scale
as needed.  It should also be flexible enough to accommodate re-writes if
you think of something that needs to be added/changed down the road 


Several of the resources and books I picked up over the past five years 
discuss this.  At the leaf level, coming up with a address plan is easy. 
 For example, I define two subnets:  one for public access, one for LAN 
use.  Each subnet has 64K addresses, far more than I need.  The firewall 
protects the LANnet



2. For providers who run older kit, v6 support might still be a bit dodgy.
You might also run into things like TCAM exhaustion, neighbor table
exhaustion, etc.  The point at which box X tips over is often not well
defined and depends on your use case and configuration.


Above my use level as a leaf node.  It may explain part of the situation 
I have with my upstream ISP...but I think the problem is more related to 
account management and not a technical one.



3. The last time I checked, v6 support in firewalls and other middle-mile
devices was still poor.  Hopefully that has gotten better in the last 6-7
years.  My current day job doesn't have me touching firewalls, so I haven't
kept up on developments here.  I recall coming up with a base firewall
ruleset for Cisco ASAs to balance security with the functionality v6 needs
to work correctly.  Hopefully firewall vendors have gotten better about
building templates to handle some of the heavy lifting.


In Linux, there have been significant advances in firewall support. 
Part of that support was in the kernel, part was in the tools.  The 
advent of NFT (NFTABLES) further improves things.  My replacement 
firewall design is to use YAML to define the rules; a Python driver 
converts the data into rules to implement the policy.


Can't speak for others.  By the way, instead of improving IPTABLES to 
handle IPv6, the community build IP6TABLES to support IPv6.  I was told 
that all I needed to do with my BASH-implemented firewall driver was to 
add IP6TABLE commands to the existing IPTABLES rules.  I would have done 
that if my upstream provider wasn't so IPv6-hostile.  I think that would 
have been a mistake.



4. Getting people to unlearn the "NAT=Security" mindset that we were forced
to accept in the v4 world.


That was EASY for me to unlearn.  With IPv4, I never had the luxury of 
subnetting large swaths of addresses.  With IPv6, that's easy, even in 
home networks.




That said, I'm thinking about giving up completely on IPv6 -- too many 
hurdles put in the way by my 800-pound-gorilla ISP.  I'm too old to 
fight the battle any more; the ROI isn't worth the effort.  I'll be dead 
before the lack of IPv6 connectivity becomes a personal problem.

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

[Justin Streiner]

The Internet edge and core portion of deploying IPv6 - dual-stack or
otherwise - is fairly easy. I led efforts to do this at a large .edu
starting in 2010/11.  The biggest hurdles are/were/might still be:
1. Coming up with a good address plan that will do what you want and scale
as needed.  It should also be flexible enough to accommodate re-writes if
you think of something that needs to be added/changed down the road :)
2. For providers who run older kit, v6 support might still be a bit dodgy.
You might also run into things like TCAM exhaustion, neighbor table
exhaustion, etc.  The point at which box X tips over is often not well
defined and depends on your use case and configuration.
3. The last time I checked, v6 support in firewalls and other middle-mile
devices was still poor.  Hopefully that has gotten better in the last 6-7
years.  My current day job doesn't have me touching firewalls, so I haven't
kept up on developments here.  I recall coming up with a base firewall
ruleset for Cisco ASAs to balance security with the functionality v6 needs
to work correctly.  Hopefully firewall vendors have gotten better about
building templates to handle some of the heavy lifting.
4. Getting people to unlearn the "NAT=Security" mindset that we were forced
to accept in the v4 world.

Thank you
jms

On Thu, Feb 15, 2024 at 8:43 PM John Levine  wrote:

> It appears that Stephen Satchell  said:
> >Several people in NANOG have opined that there are a number of mail
> >servers on the Internet operating with IPv6 addresses.  OK.  I have a
> >mail server, which has been on the Internet for decades.  On IPv4.
> >
> >For the last four years, every attempt to get a PTR record in ip6.arpa
> >from my ISP has been rejected, usually with a nasty dismissive.
>
> I don't think you'll get much disagreement that AT is not a great ISP.
>
> One straightforward workaround is to get an IPv6 tunnel from
> Hurricane. It's free, it works, and they will delegate the rDNS
> anywhere you want. My local ISP doesn't do IPv6 at all (they're a
> rural phone company who of course say you are the only person who's
> ever asked) so until they do, HE is a quite adequate option.
>
> R's,
> John
>

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

[John Levine]

It appears that Stephen Satchell  said:
>Several people in NANOG have opined that there are a number of mail 
>servers on the Internet operating with IPv6 addresses.  OK.  I have a 
>mail server, which has been on the Internet for decades.  On IPv4.
>
>For the last four years, every attempt to get a PTR record in ip6.arpa 
>from my ISP has been rejected, usually with a nasty dismissive.

I don't think you'll get much disagreement that AT is not a great ISP.

One straightforward workaround is to get an IPv6 tunnel from
Hurricane. It's free, it works, and they will delegate the rDNS
anywhere you want. My local ISP doesn't do IPv6 at all (they're a
rural phone company who of course say you are the only person who's
ever asked) so until they do, HE is a quite adequate option.

R's,
John

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

[Mark Andrews]

Well all that shows is that your ISP  is obstructionist. If they can can enter 
a PTR record or delegate the reverse range to you for your IPv4 server they can 
do it for your IPv6 addresses. In most cases it is actually easier as address 
space is assigned on nibble boundaries (/48, /52, /56, /60, :64) so there isn’t 
a need to do multiple delegations and RFC2317 style “delegations” aren’t needed 
in IPv6. If there is a non nibble assignment just do multiple sequential 
delegations (2, 4 or 8). 

It isn’t hard to type the reverse prefix into a zone then ns then the name of a 
server, bump the serial and reload it.

e.g.

e.b.c.2.6.0.7.d.0.2.2.2.ip6.arpa. ns ns1.example.com.

Good luck.

-- 
Mark Andrews

> On 16 Feb 2024, at 04:48, Stephen Satchell  wrote:
> 
> Several people in NANOG have opined that there are a number of mail servers 
> on the Internet operating with IPv6 addresses.  OK.  I have a mail server, 
> which has been on the Internet for decades.  On IPv4.
> 
> For the last four years, every attempt to get a PTR record in ip6.arpa from 
> my ISP has been rejected, usually with a nasty dismissive.
> 
> Today, I'm trying again to get that all-important PTR record.  If I'm 
> successful, then I expect to have my mail server fully up and running in the 
> IPv6 space within 72 hours, or when the DNS changes propagate, whichever is 
> longer.

Re: IPv6 Test Pages for Fortune 500 and Top 100 web sites are back

[John Lightfoot]

Well that data is disappointing.

From: NANOG  on behalf of Owen 
DeLong via NANOG 
Date: Monday, February 12, 2024 at 5:03 PM
To: NANOG list 
Subject: IPv6 Test Pages for Fortune 500 and Top 100 web sites are back
Don’t know how much anyone will still care about these pages as there are lots 
of other sources of similar data these days.

However, I finally got around to fixing the two pages I maintain:

http://www.delong.com/ipv6_fortune500.html and
http://www.delong.com/ipv6_alexa500.html

In the case of Alexa, the page is no longer based on Alexa since Amazon 
discontinued that service and now uses the Majestic 1,000,000 as a source 
(grabs the first 500 entries from their list). This page was broken since 
Amazon discontinued the Alexa service.

The Fortune 500 site still uses the same datasource, but the script was 
crashing due to sites with borked SSL implementations which caused PERL to 
abort on an exception that I never figured out how to trap or ignore. As such, 
I’m now manually maintaining an exception list of such sites in the script and 
testing them is bypassed to prevent the script from crashing. Obviously, this 
is not ideal, but I found no better solution so far.

We now return you to your regularly scheduled NANOG chatter.

Owen

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

> On Jan 14, 2024, at 19:50, Abraham Y. Chen  wrote:
> 
> Hi, Ryan:
> 
> 1) " ... it accounts for 40% of the traffic at Google.   ":
> 
> Perhaps you were referring to the following?
> 
> https://www.google.com/intl/en/ipv6/statistics.html

> 
> 2)If so, your quotation is correct, except there are some hidden stories 
> below the surface:
> 
> A.When you Google for it with key words "IPv6 Traffic Google", the 
> first hit shows "IPv6 Adoption" that lead to the above. So, strictly 
> speaking, it is not traffic data that you are looking at.

Correct, that graph shows fraction of google unique end points that have IPv6 
capability. It does not reflect traffic at all.

> B.Above the actual graph, you will find statements, such as "  ...  
> the availability of IPv6 connectivity among Google users. " So, legally, 
> the graph is correct on its own right, but may not be exactly what you 
> thought. Reader be aware!

Correct… I do not know of a graph showing traffic as a percentage for google.

> It implies that the graph the IPv6 capability (equipment readiness) of 
> Google users, not necessarily the actual traffic they generate. The two do 
> not equate to each other.

No, it shows actual IPv6 reachable, not equipment capability. Likely there is 
some relatively close degree of correlation between fraction of users and 
fraction of traffic, but you are correct that they are independent numbers. 
It’s entirely possible, I suppose, that that 45% of endpoints  reachable via 
IPv6 represents 10% of Google traffic and doesn’t really use Google very much 
at all. OTOH, it’s equally likely that 45% of end points is actually 
responsible for 90% of Google traffic. I doubt that either of these extremes is 
likely, however.

In many ways, however, the fact that 45% of eyeball endpoints have IPv6 
reachability is much more meaningful than whatever random fraction of traffic 
they happen to represent.

>  
> 3)However, the above did seem to support what was generally said in the 
> public. Until, we found an interesting ongoing (the only one of such resource 
> that is updated about every ten minutes) statistics by AMS-IX (AMSterdam 
> Internet eXchange) :
> 
> https://stats.ams-ix.net/sflow/ipv6.html   
> 
> https://stats.ams-ix.net/sflow/ether_type.html
> a
> The second URL shows that IPv6 accounts for approximately 5.7% of the 
> overall Internet traffic that AMS-IX sees today. If one traces back through 
> the archived data, the earlier numbers were even much lower. In fact, those 
> graphs looked meaningless, because there was hardly any visible trace colored 
> for IPv6. This has been going on for at least the last one decade. So, it 
> could not be an error.

This isn’t a surprise since the vast majority of Google’s (and most other 
content providers) traffic is delivered via private network interconnect and 
not on public peering points.

> 4)We contacted AMS-IX for a possible explanation of the obvious 
> discrepancy. They politely referred us to our own ISPs. This triggered our 
> curiosity. We decided that we needed to find the full world-wide IPv6 traffic 
> data.
> 
> 5)There was an annual world-wide Internet traffic statistics and forecast 
> published by Cisco that stopped after 2017 (see URL below to the last issue). 
> We contacted Cisco in 2020 and got an eMail confirmation.
> 
> 
> https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

If you dig deeper on that, you’ll find that their data is purely estimated 
based on very limited collection.

> 6)However, there has never been any equivalent publication for the IPv6 
> by itself that we could locate.

There is an interesting bit of data from Akamai in this post:
https://www.akamai.com/blog/trends/10-years-since-world-ipv6-launch#:~:text=Akamai%27s%20IPv6%20traffic%20levels%20and%20client%20base=As%20of%20May%202022%2C%20Akamai%27s,years%20ago%20in%20February%202020.

Which reports that 2022 Akamai IPv6 traffic was over 41Tbps, up from just over 
1Gbps in 2012.

While IPv4 has grown in that same 10 years, I doubt that it has grown 
4,100,000% in that same 10 years.

> 7)In search for a possible explanation of the discrepancy between Pts. 1) 
> & 3), we came across the following article. In brief, it reported that the 
> Peering agreements among Internet backbone providers were less settled for 
> IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of IPv4 
> should have been directed through the IXs (Internet eXchanges), such as 
> AMS-IX.
> 
> https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

1. This is largely untrue today. Most IPv6 capable networks that peer on a 
public exchange with another IPv6 capable network set up sessions for v4 and v6 
at the same time.

2. There’s a much more plausible explanation… Most of the big eyeball networks 
and most of the big content providers don’t 

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 11:02 PM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:


An ipv4 free network would be nice, but is hardly needed. There will
always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

Um, so what? There is lots of cruft the world over that would be better 
if it finally died. Somehow we keep on. It's just a cost of doing 
business. If mobile operators can support it with their millions or even 
billions of customers, I think everybody else can too. It's not like 
ipv4 address depletion is a static problem either -- it's only going to 
get worse as time goes on so it's what's really driving opex where v6 is 
pretty much a one-off investment in comparison i'd think.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:

> An ipv4 free network would be nice, but is hardly needed. There will
> always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:26 AM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:


In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

An ipv4 free network would be nice, but is hardly needed. There will 
always be a long tail of ipv4 and so what? You deal with it at your 
borders as a piece of non-recurring engineering and that is that. The 
mobile operators model seems to be working pretty well for them and 
seems likely that it is an opex cost down for them since they don't have 
to run two networks internally nor deal with the cost of ipv4 subnets 
(or at least not as much? not sure how it exactly works). Worrying about 
whether ipv4 will ever go away misses the point, imo.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:56 AM, jordi.palet--- via NANOG wrote:
No, I’m not saying that. I’m saying "in actual deployments", which 
doesn’t mean that everyone is deploying, we are missing many ISPs, we 
are missing many enterprises.


I don't think what's going on internally with enterprise needs to change 
much if they just gatewayed to a v6 upstream instead of v4 at the border 
if they were given that option. The problem has always been with ISP's 
and routers. When v6 first started to percolate (early 90's) i looked at 
it for my embedded OS and the projects that used it and didn't figure it 
would take much effort to implement it. So for hosts i really don't 
think that was a roadblock. But if hosts don't have something upstream 
to sink v6 traffic and especially to access the public internet there's 
not much incentive to implement it or deploy it. ISP's used the excuse 
that routers didn't implement it which was definitely a huge problem but 
as it turns out it was still an excuse since a lot has changed in the 
last 20 years and still rollout continues at a glacial pace.


I think one of the more encouraging trends are ISP's and enterprises 
switching over to v6 internally as a cost saving measure to not run a 
dual network. Aren't Comcast and Facebook examples?


It's sort of disturbing that there are still people on this list that 
want to relitigate something that happened 30 years ago. that reeks of 
religion not tech. By all means, set up CGNAT's in a pique.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

I strongly disagree that IPv6 is very much an afterthought.

A perfect example is that in Australia, our largest mobile network provider
Telstra, has completely moved to IPv6 single-stack on their mobile network
for pre-paid and post-paid customers. Russell Langton made the announcement
in February 2020 that Telstra was making the transition and they have since
completed this transition. T-Mobile US also went single-stack back in 2014.
India, with a population of 1.43 billion people (accounting for 17% of the
world's population, sits at 81.24% capable, 80.71% preferred.

With a global rate of 36.49% IPv6 capable and 35.61% IPv6 preferred, we
still have a long way to go however our current achievements to-date should
be commended.

Regards,
Christopher Hawker

Links:
https://lists.ausnog.net/pipermail/ausnog/2020-February/043869.html
https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
https://stats.labs.apnic.net/ipv6

On Mon, 15 Jan 2024 at 20:09, Saku Ytti  wrote:

> On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG 
> wrote:
>
> > No, I’m not saying that. I’m saying "in actual deployments", which
> doesn’t mean that everyone is deploying, we are missing many ISPs, we are
> missing many enterprises.
>
> Because of low entropy of A-B pairs in bps volume, seeing massive
> amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
> success. I don't disagree with your assertion, I just think it's
> damaging, because readers without context will form an idea that
> things are going smoothly.  We should rightly be in panic mode and
> forget all the IPv4 extension crap and start thinking how do we ensure
> IPv6 happens and how do we ensure we get back to single stack
> Internet.
>
> IPv6 is very much an afterthought, a 2nd class citizen today. You can
> deploy new features and software without IPv6, and it's fine. IPv6 can
> be broken, and it's not an all-hands-on-deck problem, no one is
> calling.
>
> --
>   ++ytti
>

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG  wrote:

> No, I’m not saying that. I’m saying "in actual deployments", which doesn’t 
> mean that everyone is deploying, we are missing many ISPs, we are missing 
> many enterprises.

Because of low entropy of A-B pairs in bps volume, seeing massive
amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
success. I don't disagree with your assertion, I just think it's
damaging, because readers without context will form an idea that
things are going smoothly.  We should rightly be in panic mode and
forget all the IPv4 extension crap and start thinking how do we ensure
IPv6 happens and how do we ensure we get back to single stack
Internet.

IPv6 is very much an afterthought, a 2nd class citizen today. You can
deploy new features and software without IPv6, and it's fine. IPv6 can
be broken, and it's not an all-hands-on-deck problem, no one is
calling.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[jordi.palet--- via NANOG]

No, I’m not saying that. I’m saying "in actual deployments", which doesn’t mean 
that everyone is deploying, we are missing many ISPs, we are missing many 
enterprises.

Saludos,
Jordi

@jordipalet


> El 15 ene 2024, a las 9:26, Saku Ytti  escribió:
> 
> On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  
> wrote:
> 
>> In actual customer deployments I see the same levels, even up to 85% of IPv6 
>> traffic. It basically depends on the usage of the caches and the % of 
>> residential vs corporate customers.
> 
> You think you are contributing to the IPv6 cause, by explaining how
> positive the situation is. But in reality you are damaging it greatly,
> because you're not communicating that we are not on a path to IPv4
> free Internet. If we had been on such a path, we would have been IPv4
> free for more than a decade. And unless we admit we are not on that
> path, we will not work to get on that path.
> 
> -- 
>  ++ytti



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:

> In actual customer deployments I see the same levels, even up to 85% of IPv6 
> traffic. It basically depends on the usage of the caches and the % of 
> residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[jordi.palet--- via NANOG]

All those measurements are missing the amount of traffic in the caches located 
at the ISPs.

For each download passing thru AMSIX, there are thousands of multiples of that 
download (videos, music, documents, static contents, OS updates, etc.) flowing 
to thousands of customers. In some cases is even hundreds of thousands, or even 
millions.

There is not an easy way to measure IPv6 traffic, unless it is done at the ISP 
level, and if you as, to ISPs that have deployed IPv6, they will tell you 
different numbers. For example, T-Mobile already explained a few years ago in 
v6ops that they were having over 75% of IPv6 traffic, 24% in the NAT64 and 1% 
in the CLAT+NAT64.

In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

Regards,
Jordi

@jordipalet


> El 15 ene 2024, a las 7:50, Saku Ytti  escribió:
> 
> On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) 
> mailto:li...@packetflux.com>> wrote:
> 
>> If 50٪ of the servers and 50% of the clients can do IPv6, the amount of IPv6 
>> traffic will be around 25% since both ends have to do IPv6.
> 
> This assumes cosmological principle applies to the Internet, but Internet 
> traffic is not uniformly distributed.
> 
> It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40% are 
> bps shares, and both are correct. Because AMSIX sees large entropy between 
> A-B end-points, GOOG sees very low entropy, it being always the B. 
> 
> Certain tier1 transit network could see traffic being >50% IPv6 between two 
> specific pops, so great IPv6 adoption? Except it was a single CDN sending 
> traffic from them to them, if you'd exclude that CDN flows between the pop, 
> the IPv6 traffic share was low single digit percentage. 
> 
> I am not saying IPv6 traffic is not increasing, I am saying that we are not 
> doing any favours to anyone, pretending we are on-track and that this will 
> happen, and that there are organic drivers which will ensure we are going to 
> end up with IPV6-only Internet.
> 
> --
>   ++ytti



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <
li...@packetflux.com> wrote:

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
> IPv6 traffic will be around 25% since both ends have to do IPv6.
>

This assumes cosmological principle applies to the Internet, but Internet
traffic is not uniformly distributed.

It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40%
are bps shares, and both are correct. Because AMSIX sees large entropy
between A-B end-points, GOOG sees very low entropy, it being always the B.

Certain tier1 transit network could see traffic being >50% IPv6 between two
specific pops, so great IPv6 adoption? Except it was a single CDN sending
traffic from them to them, if you'd exclude that CDN flows between the pop,
the IPv6 traffic share was low single digit percentage.

I am not saying IPv6 traffic is not increasing, I am saying that we are not
doing any favours to anyone, pretending we are on-track and that this will
happen, and that there are organic drivers which will ensure we are going
to end up with IPV6-only Internet.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Forrest Christian (List Account)]

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
IPv6 traffic will be around 25% since both ends have to do IPv6.

If you're running an IPv6 enabled server you'll see 50% of your traffic as
IPv6 in the above scenario.   Likewise, if you are on an IPv6 connected
client, then you'll also see 50٪ of your traffic as IPv6.

Note that if your adoption rates are lower, say 30% and 40%, your IPv6
traffic will be lower..  around 12% in the 30/40٪ scenario.

Cloudflare has an interesting analysis.
https://blog.cloudflare.com/ipv6-from-dns-pov#:~:text=IPv6%20Adoption%20on%20the%20Server%20Side,-The%20following%20graph=IPv6%20adoption%20by%20servers%20is,what%20was%20observed%20for%20clients
.

On Sun, Jan 14, 2024, 8:51 PM Abraham Y. Chen  wrote:

> Hi, Ryan:
>
> 1) " ... it accounts for 40% of the traffic at Google.   ":
>
> Perhaps you were referring to the following?
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
> 2)If so, your quotation is correct, except there are some hidden
> stories below the surface:
>
> A.When you Google for it with key words "IPv6 Traffic Google", the
> first hit shows "IPv6 *Adoption*" that lead to the above. So, strictly
> speaking, it is *not traffic *data that you are looking at.
>
> B.Above the actual graph, you will find statements, such as "
> ...  the *availability of IPv6 connectivity* among Google users. "
> So, legally, the graph is correct on its own right, but may not be exactly
> what you thought. Reader be aware!
>
> It implies that the graph the IPv6 capability (equipment readiness) of
> Google users, not necessarily the actual traffic they generate. The two do
> not equate to each other.
>
> 3)However, the above did seem to support what was generally said in
> the public. Until, we found an interesting ongoing (the only one of such
> resource that is updated about every ten minutes) statistics by AMS-IX
> (AMSterdam Internet eXchange) :
>
> https://stats.ams-ix.net/sflow/ipv6.html
>
> https://stats.ams-ix.net/sflow/ether_type.html
> a
> The second URL shows that IPv6 accounts for approximately 5.7% of the
> overall Internet traffic that AMS-IX sees today. If one traces back through
> the archived data, the earlier numbers were even much lower. In fact, those
> graphs looked meaningless, because there was hardly any visible trace
> colored for IPv6. This has been going on for at least the last one decade.
> So, it could not be an error.
>
> 4)We contacted AMS-IX for a possible explanation of the obvious
> discrepancy. They politely referred us to our own ISPs. This triggered our
> curiosity. We decided that we needed to find the full world-wide IPv6
> traffic data.
>
> 5)There was an annual world-wide Internet traffic statistics and
> forecast published by Cisco that stopped after 2017 (see URL below to the
> last issue). We contacted Cisco in 2020 and got an eMail confirmation.
>
>
> https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf
>
> 6)However, there has never been any equivalent publication for the
> IPv6 by itself that we could locate.
>
> 7)In search for a possible explanation of the discrepancy between Pts.
> 1) & 3), we came across the following article. In brief, it reported that
> the Peering agreements among Internet backbone providers were less settled
> for IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of
> IPv4 should have been directed through the IXs (Internet eXchanges), such
> as AMS-IX.
>
> https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/
>
> 8)The conclusion of Pt. 7) furthered our puzzlement, because it was
> opposite to what we were hoping for. That is, the roughly 5.7% IPv6 traffic
> that AMS-IX sees implies that within the overall Internet, the IPv6 traffic
> should be even less than 5.7%, not as high as Google's 40+% (Adoption)
> rate. Since we did not have the resources to further the research on this
> topic, we saved the above summary to share with anyone interested in
> pursuing for a better understanding. It will be much appreciated, if you
> could share your insights of this topic.
>
> Regards,
>
>
> Abe (2024-01-14 22:49 EST)
>
>
>
>
> On 2024-01-12 09:20, Ryan Hamel wrote:
>
> Abraham,
>
> It has existed for many years, already supported on many devices, does
> not require NAT, address space is plentiful, does not require additional
> proposals, and it accounts for 40% of the traffic at Google.
>
> Ryan
>
> --
> *From:* Abraham Y. Chen  
> *Sent:* Friday, January 12, 2024 3:45:32 AM
> *To:* Ryan Hamel  
> *Cc:* nanog@nanog.org  ; Michael Butler
>  ; Chen, Abraham
> Y.  
> *Subject:* IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4
> address block
>
>
> Caution: This is an external email and may be malicious. Please take care
> when clicking links or opening attachments.
>
> Hi, Ryan:
>
> 1)   " ...  

IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Ryan:

1) " ... it accounts for 40% of the traffic at Google.   ":

    Perhaps you were referring to the following?

https://www.google.com/intl/en/ipv6/statistics.html

2)    If so, your quotation is correct, except there are some hidden 
stories below the surface:


    A.    When you Google for it with key words "IPv6 Traffic Google", 
the first hit shows "IPv6 *_/Adoption/_*" that lead to the above. So, 
strictly speaking, it is _/*not traffic */_data that you are looking at.


    B.    Above the actual graph, you will find statements, such as " 
... the *_/availability of IPv6 connectivity/_*_/**/_among Google users. 
" So, legally, the graph is correct on its own right, but may not be 
exactly what you thought. Reader be aware!


    It implies that the graph the IPv6 capability (equipment readiness) 
of Google users, not necessarily the actual traffic they generate. The 
two do not equate to each other.
3)    However, the above did seem to support what was generally said in 
the public. Until, we found an interesting ongoing (the only one of such 
resource that is updated about every ten minutes) statistics by AMS-IX 
(AMSterdam Internet eXchange) :


https://stats.ams-ix.net/sflow/ipv6.html

https://stats.ams-ix.net/sflow/ether_type.html
a
    The second URL shows that IPv6 accounts for approximately 5.7% of 
the overall Internet traffic that AMS-IX sees today. If one traces back 
through the archived data, the earlier numbers were even much lower. In 
fact, those graphs looked meaningless, because there was hardly any 
visible trace colored for IPv6. This has been going on for at least the 
last one decade. So, it could not be an error.


4)    We contacted AMS-IX for a possible explanation of the obvious 
discrepancy. They politely referred us to our own ISPs. This triggered 
our curiosity. We decided that we needed to find the full world-wide 
IPv6 traffic data.


5)    There was an annual world-wide Internet traffic statistics and 
forecast published by Cisco that stopped after 2017 (see URL below to 
the last issue). We contacted Cisco in 2020 and got an eMail confirmation.


https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

6)    However, there has never been any equivalent publication for the 
IPv6 by itself that we could locate.


7)    In search for a possible explanation of the discrepancy between 
Pts. 1) & 3), we came across the following article. In brief, it 
reported that the Peering agreements among Internet backbone providers 
were less settled for IPv6 than IPv4. Thus, higher percentage of IPv6 
traffic than that of IPv4 should have been directed through the IXs 
(Internet eXchanges), such as AMS-IX.


https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

8)    The conclusion of Pt. 7) furthered our puzzlement, because it was 
opposite to what we were hoping for. That is, the roughly 5.7% IPv6 
traffic that AMS-IX sees implies that within the overall Internet, the 
IPv6 traffic should be even less than 5.7%, not as high as Google's 40+% 
(Adoption) rate. Since we did not have the resources to further the 
research on this topic, we saved the above summary to share with anyone 
interested in pursuing for a better understanding. It will be much 
appreciated, if you could share your insights of this topic.


Regards,


Abe (2024-01-14 22:49 EST)




On 2024-01-12 09:20, Ryan Hamel wrote:

Abraham,

It has existed for many years, already supported on many devices, does 
not require NAT, address space is plentiful, does not require 
additional proposals, and it accounts for 40% of the traffic at Google.


Ryan


*From:* Abraham Y. Chen 
*Sent:* Friday, January 12, 2024 3:45:32 AM
*To:* Ryan Hamel 
*Cc:* nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
*Subject:* IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 
address block



Caution: This is an external email and may be malicious. Please take 
care when clicking links or opening attachments.



Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement 
IPv6.    ":


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)





--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Oliver O'Boyle]

Thank you, everyone, for your responses.

Abe, I appreciate your enthisam but it is obvious you are not interested in
collaboration. You are singularly-minded and trollish.

I am assigning your email address to my spam filters. I will not see any
future communication from you.

O.


On Sat, Jan 13, 2024, 4:13 p.m. Abraham Y. Chen  wrote:

> Hi, Seth:
>
> 0)Thanks for bringing up this pair of Drafts.
>
> 1)While I believe your "IPv4 Unicast Extension" team carried on with
> the first, Avinta got accidentally exposed to the second. After analyzed
> the hurdle it faced in adding on to RFC1918, the EzIP Project is now
> focusing on enhancing CG-NAT by expanding  RFC6598.
>
> Regards,
>
>
> Abe (2024-01-13 16:08)
>
> On 2024-01-12 14:45, Seth David Schoen wrote:
>
> Michael Thomas writes:
>
>
> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.
>
> In 2008 there were two proposals
> https://datatracker.ietf.org/doc/draft-fuller-240space/https://datatracker.ietf.org/doc/draft-wilson-class-e/
>
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_2842409467345373561_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Seth:

0)    Thanks for bringing up this pair of Drafts.

1)    While I believe your "IPv4 Unicast Extension" team carried on with 
the first, Avinta got accidentally exposed to the second. After analyzed 
the hurdle it faced in adding on to RFC1918, the EzIP Project is now 
focusing on enhancing CG-NAT by expanding  RFC6598.


Regards,


Abe (2024-01-13 16:08)

On 2024-01-12 14:45, Seth David Schoen wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 11:54 AM, Darrel Lewis wrote:

On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.

IMHO, this is what you get when religion is mixed with engineering.


But it wouldn't be globally routable so it wouldn't change much. I'm not 
even sure it would change much on the ground for CGNAT deployment? You 
still need enough public addresses to service the load. It might make it 
easier than partitioning your internal net into multiple 10/8 but on the 
other hand you need to make certain your internal net still works with 
240/4.


I'm mostly throwing this out there as a way to shut down these kinds of 
discussions.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Darrel Lewis]

> On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:
> 
> Michael Thomas writes:
> 
>> I wonder if the right thing to do is to create a standards track RFC that
>> makes the experimental space officially an add on to rfc 1918. If it works
>> for you, great, if not your problem. It would at least stop all of these
>> recurring arguments that we could salvage it for public use when the
>> knowability of whether it could work is zero.
> 
> In 2008 there were two proposals
> 
> https://datatracker.ietf.org/doc/draft-fuller-240space/
> https://datatracker.ietf.org/doc/draft-wilson-class-e/
> 
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.   

IMHO, this is what you get when religion is mixed with engineering.

-Darrel

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Seth David Schoen]

Michael Thomas writes:

> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 8:45 AM, Owen DeLong via NANOG wrote:
Frankly, I care less. No matter how you use whatever IPv4 space you 
attempt to cajole into whatever new form of degraded service, the 
simple fact remains. IPv4 is a degraded technology that only continues 
to get worse over time. NAT was bad. CGNAT is even worse (and 
tragically does nothing to eliminate consumer NAT, just layers more 
disaster on top of the existing mess).


The only currently available end to end peer to peer technology, for 
better or worse, is IPv6. Despite its naysayers, it is a proven 
technology that has been shouldering a significant fraction of 
internet traffic for many years now and that fraction continues to grow.


You simply can’t make IPv4 adequate and more hackers to extend its 
life merely expands the amount of pain and suffering we must endure 
before it is finally retired.


I wonder if the right thing to do is to create a standards track RFC 
that makes the experimental space officially an add on to rfc 1918. If 
it works for you, great, if not your problem. It would at least stop all 
of these recurring arguments that we could salvage it for public use 
when the knowability of whether it could work is zero.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[borg]

I could NOT agree more. Even tho, I am IPv6 phobic, let IPv4 go away.
At least, make it go away from mainstream commercial Internet.
90% users do NOT care about it. They want to browse web, watch movies
or play games. They can do it using IPv6.
I cant wait :) more IPv4 address space for people like me and our projects.


-- Original message --

From: Owen DeLong via NANOG 
To: Abraham Y. Chen 
Cc: "Chen, Abraham Y." , nanog@nanog.org
Subject: Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address
block
Date: Fri, 12 Jan 2024 08:45:22 -0800

Frankly, I care less. No matter how you use whatever IPv4 space you
attempt to cajole into whatever new form of degraded service, the simple
fact remains. IPv4 is a degraded technology that only continues to get
worse over time. NAT was bad. CGNAT is even worse (and tragically does
nothing to eliminate consumer NAT, just layers more disaster on top of
the existing mess). 

The only currently available end to end peer to peer technology, for
better or worse, is IPv6. Despite its naysayers, it is a proven
technology that has been shouldering a significant fraction of internet
traffic for many years now and that fraction continues to grow.

You simply can˙˙t make IPv4 adequate and more hackers to extend its life
merely expands the amount of pain and suffering we must endure before it
is finally retired. 

Owen


  On Jan 12, 2024, at 03:46, Abraham Y. Chen
   wrote:

  ˙˙ Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement
IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
  Abraham,

You're arguing semantics instead of the actual
point. Residential customers want Internet access, not
intranet access. Again, VRFs are plentiful and so are CG-NAT
firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG  on
behalf of Abraham Y. Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
Cc: nanog@nanog.org 
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4
address block


Caution: This is an external email and may be malicious.
Please take care when clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A
to B in a private setting, using them might also be .. a
challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional
Area Network) as "Private" address, not "publicly" routable,
according to the conventional Internet definition. This is
actually the same as how 100.64/10 is used within CG-NAT. 

2)However, this might be where the confusion comes from.
With the geographical area coverage so much bigger, an RAN is
effectively a public network. To mesh the two for
consistency, we defined everything related to 240/4 as
"Semi-Public" to distinguish this new layer of networking
facility from the current public / private separation. That
is, the CG-NAT routers will become SPRs (Semi-Public Routers)
in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)
 


On 2024-01-10 10:45, Michael Butler via NANOG wrote:
  On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice,
and understand the full context.

240/4 is still classified as RESERVED
space. While you would certainly be
able to use it on internal networks
if your equipment supports it, you
cannot use it as publicly routable
space. There have been many proposals
over the years to reclassify 240/4,
but that has not happened, and is
unlikely to at any point in the
foreseeable future.


  While you may be able to get packets from point A
  to B in a private setting, using them might also
  be .. a challenge.

  There's a whole bunch of software out there that
  makes certain assumptions about allowable ranges.
  That is, they've been compiled with a header that
  defines ..

  #define IN_BADCLASS(i)(((in_addr_t)(i) &
  0xf000) == 0xf000)

  Michael



[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to eliminate consumer NAT, just layers more disaster on top of the existing mess). The only currently available end to end peer to peer technology, for better or worse, is IPv6. Despite its naysayers, it is a proven technology that has been shouldering a significant fraction of internet traffic for many years now and that fraction continues to grow.You simply can’t make IPv4 adequate and more hackers to extend its life merely expands the amount of pain and suffering we must endure before it is finally retired. OwenOn Jan 12, 2024, at 03:46, Abraham Y. Chen  wrote:

  

  
  
Hi, Ryan:

   
1)   " ...  Save
yourself the time and effort on this and implement IPv6.    ":

   
    What is your selling
point?

  

  
Regards,

  

  
Abe (2024-01-12 06:44)









2024-01-11 12:39, Ryan Hamel wrote:


  
  Abraham,
  
  
  You're arguing semantics instead of the actual
point. Residential
  customers want Internet access, not intranet access.
Again, VRFs are plentiful and so are CG-NAT firewall appliances
or servers to run those VMs. 
  
  
  Save yourself the time and effort on this and
implement IPv6.
  


Ryan
  
  

From:
  NANOG 
  on behalf of Abraham Y. Chen 
  Sent: Thursday, January 11, 2024 9:24:18 AM
  To: Michael Butler 
  Cc: nanog@nanog.org 
  Subject: Where to Use 240/4 Re:
  202401100645.AYC Re: IPv4 address block



  

  
  
  
Caution:
  This is an external email and may be malicious. Please
  take care when clicking links or opening attachments.

  

  



  Hi, Michael:
  

  1)    " ... While
  you may be able to get packets from point A to B in a
  private setting, using them might also be .. a challenge.
  ...   ":
  

      EzIP uses
  240/4 netblock only within the RAN (Regional Area Network)
as "Private" address, not "publicly" routable, according to the
  conventional Internet definition. This is actually the
  same as how 100.64/10 is used within CG-NAT. 
  

  2)    However,
  this might be where the confusion comes from. With the
  geographical area coverage so much bigger, an RAN is
  effectively a public network. To mesh the two for
  consistency, we defined everything related to 240/4 as
  "Semi-Public" to distinguish this new layer of networking
  facility from the current public / private separation.
  That is, the CG-NAT routers will become SPRs (Semi-Public
  Routers) in EzIP's RAN, once the 240/4 is deployed.

  

  Hope this helps,
  

  

  Abe (2024-01-11
  12:21)
  
   
  
  
  
  
  
  On 2024-01-10 10:45, Michael
Butler via NANOG wrote:
  
  On 1/10/24 10:12, Tom Beecher wrote: 
Karim- 
  
  Please be cautious about this advice, and understand the
  full context. 
  
  240/4 is still classified as RESERVED space. While you
  would certainly be able to use it on internal networks if
  your equipment supports it, you cannot use it as
  publicly routable space. There have been many proposals
  over the years to reclassify 240/4, but that has not
  happened, and is unlikely to at any point in the
  foreseeable future. 


While you may be able to get packets from point A to B in a
private setting, using them might also be .. a challenge. 

There's a whole bunch of software out there that makes
certain assumptions about allowable ranges. That is, they've
been compiled with a header that defines .. 

#define IN_BADCLASS(i)    (((in_addr_t)(i) & 0xf000)
== 0xf000) 

Michael 

  
  
  
 

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

It has existed for many years, already supported on many devices, does not 
require NAT, address space is plentiful, does not require additional proposals, 
and it accounts for 40% of the traffic at Google.

Ryan


From: Abraham Y. Chen 
Sent: Friday, January 12, 2024 3:45:32 AM
To: Ryan Hamel 
Cc: nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
Subject: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address 
block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
Abraham,

You're arguing semantics instead of the actual point. Residential customers 
want Internet access, not intranet access. Again, VRFs are plentiful and so are 
CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG 

 on behalf of Abraham Y. Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 

Cc: nanog@nanog.org 

Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block


Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as 
"Private" address, not "publicly" routable, according to the conventional 
Internet definition. This is actually the same as how 100.64/10 is used within 
CG-NAT.

2)However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a public 
network. To mesh the two for consistency, we defined everything related to 
240/4 as "Semi-Public" to distinguish this new layer of networking facility 
from the current public / private separation. That is, the CG-NAT routers will 
become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:
On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

While you may be able to get packets from point A to B in a private setting, 
using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions 
about allowable ranges. That is, they've been compiled with a header that 
defines ..

#define IN_BADCLASS(i)(((in_addr_t)(i) & 0xf000) == 0xf000)

Michael



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  
Virus-free.www.avast.com

Re: ipv6 address management - documentation

[owen--- via NANOG]

> On Nov 16, 2023, at 21:57, Ryan Hamel  wrote:
> 
> Christopher,
> 
> A residential customer would be getting their /56 from the providers pool via 
> RA or DHCPv6. With a /32 aggregate, it can handle 1.6 million /56 
> delegations, which can cover a few regions. It all depends on the planning 
> going into splitting up the aggregate.

Or, if the provider isn’t stingy a /48 from the providers /≤32 (providers can 
get as many /48s as they need to support whatever number of customers receiving 
them, at least in the ARIN region).

> A rule of thumb I go by in the datacenter is, a /48 per customer per site, 
> and further splitting it into /64s per VLAN, all of which can be plugged into 
> a spreadsheet formula to produce a valid complete subnet.
> 
> Either way, keeping track of IPAM via spreadsheet is a recipe for disaster. 
> NetBox and Nautobot are my choices, and is worth deploying on a server or 
> VPS, even for home labs.

On this, we agree.

It’s just not what spreadsheets do.

Owen

> 
> Ryan
> 
> From: NANOG  on behalf of 
> Christopher Hawker 
> Sent: Thursday, November 16, 2023 3:52:59 PM
> To: Aaron Gould ; Owen DeLong 
> Cc: nanog@nanog.org 
> Subject: Re: ipv6 address management - documentation
> 
> Caution: This is an external email and may be malicious. Please take care 
> when clicking links or opening attachments.
> 
> One of the first things that comes to mind, is that if you were to breakout a 
> /64 v6 subnet (a standard-issue subnet to a residential customer) in an Excel 
> spreadsheet, the number of columns you would need is 14 digits long. You 
> could breakout the equivalent of a /12 v4 in just one column. Understandably 
> in the real world no one (in their right mind) would do this, this is just 
> for comparison.
> 
> Regards,
> Christopher H.
> From: NANOG  on behalf of Owen 
> DeLong via NANOG 
> Sent: Friday, November 17, 2023 10:39 AM
> To: Aaron Gould 
> Cc: nanog@nanog.org 
> Subject: Re: ipv6 address management - documentation
>  
> Spreadsheets are terrible for IPAM regardless of address length, but I am 
> curious to know why you think IPv6 would be particularly worse than IPv4 in 
> such a scenario?
> 
> Owen
> 
> 
> > On Nov 16, 2023, at 10:02, Aaron Gould  wrote:
> > 
> > For years I've used an MS Excel spreadsheet to manage my IPv4 addresses.  
> > IPv6 is going to be maddening to manage in a spreadsheet.  What does 
> > everyone use for their IPv6 address prefix management and documentation?  
> > Are there open source tools/apps for this?
> > 
> > -- 
> > -Aaron
> 
>