RE: IPv4 flag day

[Gary Sparkes via NANOG <nanog () lists nanog org>]

The ICMP echo request scenario is how we do the endpoint discovery so that the server knows the client's address.

After that, you start falling into more "standard" NAT traversal techniques between the two endpoints. That's what gets 
you the established NAT state/session. 

-----Original Message-----
From: William Herrin <bill () herrin us> 
Sent: Thursday, June 18, 2026 3:22 PM
To: Gary Sparkes <gary () kisaracorporation com>
Cc: North American Network Operators Group <nanog () lists nanog org>
Subject: Re: IPv4 flag day

On Thu, Jun 18, 2026 at 11:52 AM Gary Sparkes <gary () kisaracorporation com> wrote:
> Correct, I specified both firewalls have an inbound default deny, accept only related/established.
>
> The standard CPE configuration for any NAT scenario, and the usual standard for any non-NAT scenario as well.
>
> NAT allows me to *bypass* this.

Hi Gary,

You still have not demonstrated that the non-NAT version rejects the packets. You've claimed it but offered no 
explanation.

In your example, you sent ICMP echo-request packets to some random address. This would allow several types of ICMP 
packets to return to you from arbitrary IP addresses so long as they contained the same ICMP ID. After all, you have to 
be able to receive destination unreachable messages from intermediate routers. It would not allow UDP or TCP packets to 
reach you, at least not in the NAT case. Those use different translation tables which are not populated by outbound 
ICMP packets.

The ICMP return packets are allowed in both the NAT case and the non-NAT case: both have state established to accept 
returns (including error returns) to the ICMP echo-request. Neither one has state established for TCP or UDP.

Regards,
Bill Herrin


--
For hire. https://bill.herrin.us/resume/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/SNCOEMQPN44XX2CYPAHSGN44AZ6J66SU/