Hacker News Reader

Comment by X-Istence | Hacker News Reader

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

View on HN

If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet.

The load balancer will route any ongoing sessions with the session id, and not the ip address.

Absolutely, but the original commenter was stating that it would allow either endpoint to their their IP easily (and thus making load balancing easier). I was disputing that.

Ah... apologies for my confusion. Thanks for the clarification.

Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.

Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.

There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.

My firewall doesn't do NAT yet is still stateful for IPv6.

Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.

You can solve that with STUN which is how WebRTC does it. Each end sends a STUN packet to get the NAT statefullness going.

Granted, it requires transferring of ICE connection candidates out of band (via the horrors of SDP)

I think it's more about the client changing their IP, i.e. moving wifi networks or from wifi to mobile. Not so much the server changing.

Client changing their IP address is fine, the comment I was replying to was stating that it would allow both sides to change their IP at will (and allow for better load balancing). I was disputing that.

Reply on news.ycombinator.com