Re: The Reg does 240/4

[Mike Hammett]

" Think how many more sites could have IPv6 capability already if this wasted 
effort had been put into that, instead. " 


My assumption is not many because the people talking about this likely either 
already have or will not deploy IPv6. Those that are willing to deploy IPv6, 
but have not are too busy to be engaging in the conversation. Well, mostly. 





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

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

- Original Message -

From: "Owen DeLong via NANOG"  
To: "Christopher Hawker"  
Cc: "North American Operators' Group"  
Sent: Wednesday, February 14, 2024 11:23:35 AM 
Subject: Re: The Reg does 240/4 



This gift from the bad idea fairy just keeps on giving. You’ve presented your 
case numerous times. The IETF has repeatedly found no consensus for it and yet 
you persist. 


Think how many more sites could have IPv6 capability already if this wasted 
effort had been put into that, instead. 


Owen 





On Feb 13, 2024, at 14:16, Christopher Hawker  wrote: 







Hi Tom, 


We aren't trying to have a debate on this. All we can do is present our case, 
explain our reasons and hope that we can gain a consensus from the community. 


I understand that some peers don't like the idea of this happening and yes we 
understand the technical work behind getting this across the line. It's easy 
enough for us to say "this will never happen" or to put it into the "too hard" 
basket, however, the one thing I can guarantee is that will never happen, if 
nothing is done. 


Let's not think about ourselves for a moment, and think about the potential 
positive impact that this could bring. 


Regards, 
Christopher Hawker 


From: Tom Beecher  
Sent: Wednesday, February 14, 2024 1:23 AM 
To: Christopher Hawker  
Cc: North American Operators' Group ; aus...@lists.ausnog.net 
; Christopher Hawker via sanog ; 
apnic-t...@lists.apnic.net  
Subject: Re: The Reg does 240/4 




Now, we know there's definitely going to be some pushback on this. This won't 
be easy to accomplish and it will take some time. 




It won't ever be 'accomplished' by trying to debate this in the media. 


On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker < ch...@thesysadmin.au > 
wrote: 





Hello all, 


[Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SANOG 
and APNIC-Talk in order to invite more peers to engage in the discussion on 
their respective forums.] 


Just to shed some light on the article and our involvement... 


Since September 1981, 240/4 has been reserved for future use, see 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml . 
This space has always been reserved for future use and given the global 
shortage of available space for new network operators we feel it is appropriate 
for this space to be reclassified as Unicast space available for delegation by 
IANA/PTI to RIRs on behalf of ICANN. 


At present, the IP space currently available for RIRs to delegate to new 
members is minimal, if any at all. The primary goal of our call for change is 
to afford smaller players who are wanting to enter the industry the opportunity 
to do so without having to shell out the big dollars for space. Although I do 
not agree with IP space being treated as a commodity (as this was not what it 
was intended to be), those who can afford to purchase space may do so and those 
who cannot should be able to obtain space from their respective RIR without 
having to wait over a year in some cases just to obtain space. It's not 
intended to flood the market with resources that can be sold off to the highest 
bidder, and this can very well be a way for network operators to plan to 
properly roll out IPv6. At this point in time, the uptake and implementation of 
IPv6 is far too low (only 37% according to https://stats.labs.apnic.net/ipv6 ) 
for new networks to deploy IPv6 single-stack, meaning that we need to continue 
supporting IPv4 deployments. 


The reallocation of IPv4 space marked as Future Use would not restrict or 
inhibit the deployment of IPv6, if anything, in our view it will help the 
deployment through allowing these networks to service a greater number of 
customers than what a single /24 v4 prefix will allow. Entire regions of an 
economy have the potential to be serviced by a single /23 IPv4 prefix when used 
in conjunction with IPv6 space. 


Now, some have argued that we should not do anything with IPv4 and simply let 
it die out. IPv4 will be around for the foreseeable future and while it is, we 
need to allow new operators to continue deploying networks. It is unfair of us 
to say "Let's all move towards IPv6 and just let IPv4 die" however the reality 
of the situation is that while we continue to treat it as a commodity and allow 
v6 uptake to progress as slowly as it is, we need to continue supporting it v4. 
Some have also argued that networks use this space internally within their 
infrastructure. 240

Re: The Reg does 240/4

[Mike Hammett]

" Does any IPv6 enabled ISP provide PTR records for mail servers?" 


I think people will conflate doing so at ISP-scale and doing so at residential 
hobbiyst scale (and everything in between). One would expect differences in 
outcomes of attempting PTR records in DIA vs. broadband. 



"How does Google handle mail from an IPv6 server?" 


A few people have posted that it works for them, but unless it has changed 
recently, per conversations on the mailop mailing list, Google does not treat 
IPv6 and IPv4 mail the same and that causes non-null issues. 



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

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

- Original Message -

From: "Stephen Satchell"  
To: nanog@nanog.org 
Sent: Wednesday, February 14, 2024 8:25:03 PM 
Subject: Re: The Reg does 240/4 

On 2/14/24 4:23 PM, Tom Samplonius wrote: 
> The best option is what is happening right now: you can’t get new IPv4 
> addresses, so you have to either buy them, or use IPv6. The free market 
> is solving the problem right now. Another solution isn’t needed. 

Really? How many mail servers are up on IPv6? How many legacy mail 
clients can handle IPv6? How many MTA software packages can handle IPv6 
today "right out of the box" without specific configuration? 

Does any IPv6 enabled ISP provide PTR records for mail servers? 

How does Google handle mail from an IPv6 server? 

The Internet is not just the Web. 

Re: The Reg does 240/4

[Christian de Larrinaga via NANOG]

inline

Christopher Hawker  writes:

> Hi Christian,
>
> The idea to this is to allow new networks to emerge onto the internet, 
> without potentially having to fork out
> substantial amounts of money.

That would then be using IPv6 with IPv4 transition translation etc at the
ingress/egress to your new shiny ISP. 

>
> I am of the view that networks large enough to require more than a /8 v4 for 
> a private network, would be in the
> position to move towards IPv6-only. Meta has already achieved this
> (https://engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv6-only-infra/)
>  by rolling
> out dual-stack on their existing nodes and enabling new nodes as
> IPv6-only.

Any network of any size can justify using IPv6.

You will though face some old telco monopolistic / Tier 1 incumbencies
who find their benefit in networking is to be as anti social to fellow
networks as their lack of imagination on the value of connectivity can
facilitate and regret they can't charge time and distance but very happy
to charge on ingress and egress. 

>I cannot think of a bigger waste of
> resources that have the possibility of being publicly used, than to allocate 
> an additional 16 x /8 to RFC1918
> space.
>

I expect it would take many years for 240/4 to have universal
routing  as a public resource. That maybe the first challenge to get it through 
IETF

The other challenge is that the block is currently marked experimental
and really if you want to make a plan to use all or part of that
block. Then that should be for experimental purposes.

Just saying it is now public isn't really an innovation. 

Also once reallocated its lost to future experimental uses. 

> The same argument could be had about using larger than a /8 for private 
> networking. Why not use IPv6?
>

well now you are speaking hexadecimal! 

> Regards,
> Christopher Hawker


best

Christian 
> -
> From: Christian de Larrinaga 
> Sent: Wednesday, February 14, 2024 11:51 PM
> To: Christopher Hawker 
> Cc: Denis Fondras ; nanog@nanog.org 
> Subject: Re: The Reg does 240/4 
>  
> excuse top posting -
>
> I don't see a case for shifting 240/4 into public IP space if it is just
> going to sustain the rentier sinecures of the existing IPv4
> incumbencies. In other words if RIRs don't use it boost new entrants it
> will just add another knot to the stranglehold we are in vis IPv4. 
>
> I can see a potential case for shifting it from experimental to private
> space given the fact that "the rest of us" without public IP space and
> natted behind CGNATs have taken to use IPv4 for wireguard, containers,
> zero configs and so on, to tie our various locations, services and
> applications together within our own private distributed nets and expose
> our services for public consumption over IPv6.
>
> C
>
> Christian de Larrinaga
>
> Christian Christopher Hawker  writes
>
>> Hi Denis,
>>
>> It will only be burned through if RIR communities change policies to allow 
>> for larger delegations than what is
>> currently in place. I believe that some level of change is possible whilst 
>> limiting the exhaustion rate, e.g. allowing
>> for delegations up to a maximum holding of a /22, however we shouldn't go 
>> crazy (for want of a better phrase)
>> and allow for delegations of a /20, /19 etc.
>>
>> If this was only going to give us a potential 1-3 years' worth of space, 
>> then I would agree in saying that it is a
> waste
>> of time, would take far too long to make the space usable and wouldn't be 
>> worth it. However, as long as we
> don't
>> get greedy, change the maximum allowed delegation to large delegations, and 
>> every Tom/Dick/Harry applying
>> for a /16 allocation then 240/4 will last us a lengthy amount of time, at 
>> least a few decades.
>>
>> Regards,
>> Christopher Hawker
>> -
>> From: NANOG  on behalf of 
>> Denis Fondras via NANOG
>> 
>> Sent: Wednesday, February 14, 2024 11:10 PM
>> To: nanog@nanog.org 
>> Subject: Re: The Reg does 240/4 
>>  
>> Le Tue, Feb 13, 2024 at 03:24:21PM -0800, David Conrad a écrit :
>>> This doesn’t seem all that positive to me, particularly because it’s 
>>> temporary
>>> since the underlying problem (limited resource, unlimited demand) cannot be
>>> addressed.
>>> 
>>
>> I agree with this.
>> Yet I am in favor of changing the status of 240/4, just so it can get burned
>> fast, we stop this endless discussion and can start to deploy IPv6 again.
>>
>> Denis


-- 
Christian de Larrinaga 

Re: The Reg does 240/4

[Mike Hammett]

Evidence to support Tom's statement: 

https://auctions.ipv4.global/prior-sales 




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

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

- Original Message -

From: "Tom Beecher"  
To: "Brian Knight"  
Cc: nanog@nanog.org 
Sent: Thursday, February 15, 2024 5:31:42 PM 
Subject: Re: The Reg does 240/4 




$/IPv4 address peaked in 2021, and has been declining since. 





On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG < nanog@nanog.org > wrote: 


On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: 
> I've said it before, and I'll say it again: 
> 
> The only thing stopping global IPv6 deployment is 
> Netflix continuing to offer services over IPv4. 
> 
> If Netflix dropped IPv4, you would see IPv6 available *everywhere* 
> within a month. 

As others have noted, and to paraphrase a long-ago quote from this 
mailing list, I'm sure all of Netflix's competitors hope Netflix does 
that. 

I remain hopeful that the climbing price of unique, available IPv4 
addresses eventually forces migration to v6. From my armchair, only 
through economics will this situation will be resolved. 

> --lyndon 

-Brian 

RE: The Reg does 240/4

[Brotman, Alex via NANOG]

We (comcast.net) have been sending/receiving via IPv6 since 2012 or so.  We do 
have PTR records for our outbound IPv6 addresses, and expect them for inbound 
IPv6 as well.Keeping in mind that a huge portion of inbound mail is 
bulk/commercial and they have thus far largely avoided IPv6, Inbound IPv6 is 
about 5% of traffic.  Outbound IPv6 is about 40% of traffic.  I’m not sharing 
mail submissions from users as many (nearly all?) of our users have IPv6 and 
that would skew the numbers, and may not be relevant to this discussion.

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

From: NANOG  On Behalf Of 
Mike Hammett
Sent: Friday, February 16, 2024 10:20 AM
To: l...@satchell.net
Cc: nanog@nanog.org
Subject: Re: The Reg does 240/4

"Does any IPv6 enabled ISP provide PTR records for mail servers?"

I think people will conflate doing so at ISP-scale and doing so at residential 
hobbiyst scale (and everything in between). One would expect differences in 
outcomes of attempting PTR records in DIA vs. broadband.

"How does Google handle mail from an IPv6 server?"

A few people have posted that it works for them, but unless it has changed 
recently, per conversations on the mailop mailing list, Google does not treat 
IPv6 and IPv4 mail the same and that causes non-null issues.



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

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


From: "Stephen Satchell" mailto:l...@satchell.net>>
To: nanog@nanog.org
Sent: Wednesday, February 14, 2024 8:25:03 PM
Subject: Re: The Reg does 240/4

On 2/14/24 4:23 PM, Tom Samplonius wrote:
> The best option is what is happening right now:  you can’t get new IPv4
> addresses, so you have to either buy them, or use IPv6.  The free market
>   is solving the problem right now.  Another solution isn’t needed.

Really?  How many mail servers are up on IPv6?  How many legacy mail
clients can handle IPv6?  How many MTA software packages can handle IPv6
today "right out of the box" without specific configuration?

Does any IPv6 enabled ISP provide PTR records for mail servers?

How does Google handle mail from an IPv6 server?

The Internet is not just the Web.

RE: The Reg does 240/4

[Howard, Lee via NANOG]

It seems we’re the marketplace of record.

We do have some private transactions, that is, sales that take place outside of 
our marketplace and therefore don’t appear on the prior-sales page. That’s 
generally for /16 or larger, where one or both parties want custom terms that 
differ from our standard Terms of Use.

It’s true that prices for /16 and larger have held steadier than smaller 
blocks. My guess is that there has been a lot more supply of smaller blocks 
than /16+, driving prices down for the smaller blocks. Supply for /16s and 
larger is fine, but not enormous. I don’t assume that prices will remain the 
same.

So, what about 240/4?  The IPv4 market moves about 40 million addresses per 
year. A /4 is 268 million addresses, so if that supply became available (IETF 
telling IANA to distribute it to the RIRs, I assume) it would definitely affect 
the market for a long time. The RIRs would have to look at their 
post-exhaustion policies and figure out whether they still applied, or if 
pre-exhaustion policies should be used. I don’t have a strong opinion on this, 
and give credit to the authors of the proposal for working to identify any 
places where 240/4 would not work.

I still think the Internet works better when everyone uses the same protocol, 
so everyone should deploy IPv6. At this point, the consumer electronics and 
corporate IT sectors are the major holdouts. There are still ISPs and web sites 
that don’t have IPv6, but it’s no longer reasonable to assert that those are 
failures as a group, IMHO.


Lee Howard | Senior Vice President, IPv4.Global
[Inline image]

t: 646.651.1950
email: leehow...@hilcostreambank.com
web: www.ipv4.global
twitter: twitter.com/ipv4g





From: NANOG  On Behalf 
Of Mike Hammett
Sent: Friday, February 16, 2024 10:28 AM
To: Tom Beecher 
Cc: nanog@nanog.org
Subject: Re: The Reg does 240/4

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


Evidence to support Tom's statement:

https://auctions.ipv4.global/prior-sales


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

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


From: "Tom Beecher" mailto:beec...@beecher.cc>>
To: "Brian Knight" mailto:m...@knight-networks.com>>
Cc: nanog@nanog.org
Sent: Thursday, February 15, 2024 5:31:42 PM
Subject: Re: The Reg does 240/4
$/IPv4 address peaked in 2021, and has been declining since.

On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG 
mailto:nanog@nanog.org>> wrote:
On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> I've said it before, and I'll say it again:
>
>   The only thing stopping global IPv6 deployment is
>   Netflix continuing to offer services over IPv4.
>
> If Netflix dropped IPv4, you would see IPv6 available *everywhere*
> within a month.

As others have noted, and to paraphrase a long-ago quote from this
mailing list, I'm sure all of Netflix's competitors hope Netflix does
that.

I remain hopeful that the climbing price of unique, available IPv4
addresses eventually forces migration to v6. From my armchair, only
through economics will this situation will be resolved.

> --lyndon

-Brian

Re: AWS WAF list

[Justin H.]

Justin H. wrote:

Hello,

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


We're finding it difficult to find a technical contact that we can 
reach since we're not an AWS customer.  Does anyone have a contact or 
advice on a solution?
Sadly we're not getting any traction from standard AWS support, and end 
users of the WAF list like Reddit and Eventbrite are refusing to 
whitelist anyone.  Does anyone have any AWS contacts that might be able 
to assist?  Our enterprise customers are becoming more and more impacted.


Justin H.

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 17 Feb, 2024

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  942295
Prefixes after maximum aggregation (per Origin AS):  358047
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  457204
Total ASes present in the Internet Routing Table: 75421
Prefixes per ASN: 12.49
Origin-only ASes present in the Internet Routing Table:   64642
Origin ASes announcing only one prefix:   26587
Transit ASes present in the Internet Routing Table:   10779
Transit-only ASes present in the Internet Routing Table:502
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible: 121
Max AS path prepend of ASN (150315) 116
Prefixes from unregistered ASNs in the Routing Table:  1075
Number of instances of unregistered ASNs:  1085
Number of 32-bit ASNs allocated by the RIRs:  43662
Number of 32-bit ASNs visible in the Routing Table:   35885
Prefixes from 32-bit ASNs in the Routing Table:  181653
Number of bogon 32-bit ASNs visible in the Routing Table:65
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:515
Number of addresses announced to Internet:   3042124416
Equivalent to 181 /8s, 83 /16s and 34 /24s
Percentage of available address space announced:   82.2
Percentage of allocated address space announced:   82.2
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  311250

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   251971
Total APNIC prefixes after maximum aggregation:   72931
APNIC Deaggregation factor:3.45
Prefixes being announced from the APNIC address blocks:  244695
Unique aggregates announced from the APNIC address blocks:   100135
APNIC Region origin ASes present in the Internet Routing Table:   13993
APNIC Prefixes per ASN:   17.49
APNIC Region origin ASes announcing only one prefix:   4233
APNIC Region transit ASes present in the Internet Routing Table:   1890
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible:121
Number of APNIC region 32-bit ASNs visible in the Routing Table:   9361
Number of APNIC addresses announced to Internet:  774459264
Equivalent to 46 /8s, 41 /16s and 79 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:274991
Total ARIN prefixes after maximum aggregation:   123700
ARIN Deaggregation factor: 2.22
Prefixes being announced from the ARIN address blocks:   279962
Unique aggregates announced from the ARIN address blocks:132230
ARIN Region origin ASes present in the Internet Routing Table:19096
ARIN Prefixes per ASN:  

Re: The Reg does 240/4

[John Levine]

It appears that Mike Hammett  said:
>-=-=-=-=-=-
>
>" Does any IPv6 enabled ISP provide PTR records for mail servers?" 
>
>
>I think people will conflate doing so at ISP-scale and doing so at residential 
>hobbiyst scale (and everything in between). One would
>expect differences in outcomes of attempting PTR records in DIA vs. broadband. 

Most consumer ISPs block port 25 so rDNS would be the least of your problems 
trying to run a home mail server.

>"How does Google handle mail from an IPv6 server?" 
>
>A few people have posted that it works for them, but unless it has changed 
>recently, per conversations on the mailop mailing list,
>Google does not treat IPv6 and IPv4 mail the same and that causes non-null 
>issues. 

As has been widely reported, Google has recently tightened up authentication 
requirements so
v4 and v6 are now pretty similar.

They won't accept v6 mail that isn't authenticated with SPF or DKIM
but honestly, if you can't figure out how to publish an SPF record you
shouldn't try to run a mail server.

R's,
John

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)

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

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

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

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

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

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

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

[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&data=05%7C02%7Cryan%40rkhtech.org%7C5672986956c34e345fd208dc2f5a571c%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437312255883842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iuKWxWts%2B9buTCz318C7hz6DbuWSST%2FKPZAWbbhSj8Q%3D&reserved=0

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: Verizon Business Contact

[Richard Laager]

On 2024-02-09 18:10, Justin Krejci wrote:
For a good long while (months) we have had similar issues with various 
Verizon destinations.


Only Verizon *Wireless* destinations, or other Verizon *Business* things?

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


--
Richard

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

[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&data=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D&reserved=0