Comment by ivlad | Hacker News Reader

Comment by ivlad | Hacker News Reader

Parent Full thread

Before I start I must say, I built IPv6 only datacenters and enterprise networks. I am saying from experience.

> Can’t just simply put one IPv6 router/firewall behind another. Not all IPv6 routers support DHCP-PD, and even if they did, you could have 2-3-4 levels of routers/firewalls at a business.

You cannot do this with IPv4 either. Routing has to work. It works for both IPv4 and In But if you are saying, you add 2-3-4 layers of NAT, this is just crazy.

> Can’t just simply open a firewall rule on the main site router to forward say HTTPS to an internal service. Why? Not all ISPs give static IPv6 prefixes, not all PCs/servers/devices support DHCP6 for static leases, and then there’s IPv6 privacy addresses.

ISPs not providing static prefixes is a particular ISP problem, not an IPv6 problem. If your ISP cannot hand out static IPv4, you have a similar problem and tge workaround would be what? Dynamic DNS? Admittedly we had /32 and own ASN, but in remote offices where you don’t buy transit, you live on PA addresses (and of course they are static). From what I know, some ISPs don’t issue static prefixes to residential customers, but if you want to serve services from your prefix, use a stable prefix and a decent ISP.

Privacy addresses are intended for client-initiated traffic, so no matter how many privacy addresses your server has, the stable one is still there.

> WAN failover / multiple ISPs is hard. You have a fibre primary feed, and a secondary cellular/5G feed. Each has different IPv6 addresses. How do you ensure the right ISP is used at any given point?

By sending RA and expiring the old prefix on the failover. I admit, this is not an obvious solution and it may not be suitable for some edge cases.

Datacenter networks are an entirely different beast to SME and SOHO business networks. You don’t get the same budget for nice equipment, nor dedicated IT persons to run it, nor any remotely technical people on the ISP side to help you. SME and SOHO are very price conscious too. Think low margin retail and petroleum and fastfood.

> You cannot do this with IPv4 either. Routing has to work. It works for both IPv4 and In But if you are saying, you add 2-3-4 layers of NAT, this is just crazy.

Yes, you literally can stack a dozen commercial IPv4 firewall/routers behind each others networks and a PC plugged into the very last one will have no problems access Google on the browser. Because of NAT, which all IPv4 capable personal/SOHO/SME routers do by default.

Sure, VoIP may not work, but actually chances are it will because the VoIP service will be NAT-free via VPN to the provider.

And in this retail/petro/fastfood environment things like p2p file sharing are irrelevant and not required. All traffic is either to websites or to corporate systems across VPNs where NAT is not present or easily managed.

> By sending RA and expiring the old prefix on the failover. I admit, this is not an obvious solution and it may not be suitable for some edge cases.

It’s a slow failover by comparison to IPv4 methods. Too slow for some common use cases in industries I deal with. It also doesn’t allow for load balancing across links (eg route all important traffic out link 1 by default and all backup uploads out link 2 by default).

> Datacenter networks are an entirely different beast to SME and SOHO business networks.

SOHO networks just use what providers gives them. I am not sure, why are you jumping from large “oil-and-gas corps” to SOHO, though.

For SOHO providers will be building IPv6-only networks with NAT64 to access the legacy IP. I am seeing it happening: I saw multiple situations like this with guest wifi already. Obviously, this trend is going to continue.

> Yes, you literally can stack a dozen commercial IPv4 firewall/routers behind each others networks and a PC plugged into the very last one will have no problems access Google on the browser. Because of NAT, which all IPv4 capable personal/SOHO/SME routers do by default.

… and then Google blocks it all because the amount of requests from a single IP exceeds their expectations. I have seen half of Belarus blocked by Google because their NAT pools were overprovisioned. When I was at Cisco, a customer asked us to change the NAT behaviour so, that it uses pool not “first, all ports from the first IP in the pool, then all ports from the second IP, etc” to “first port from the first IP, then the first port from the second IP, etc”. The reason was, their starting IPs in the pool were always oversubscribed and blocked. The alternative behaviour broke FTP, SIP even with application-level fixups because the protocols don’t expect signalling and data to use different IPs.

Not to mention, SOHO routers just don’t have enough capacity to maintain translation cache so connections will be randomly dropped.

> Too slow for some common use cases in industries I deal with.

Have you tried it? Renumbering event means sending two RA packets: one to expire an old prefix, another to announce a new one. While technically it’s slower than changing routers on the NAT gateway, I wonder what are your requirements.

It doesn’t allow load balancing, which is true. Work is being done in IETF to support for client-based load balancing, see RFC7157, etc. In my experience, load balancing is rarely happening in such scenarios because it will result an overloaded link when either on two goes down. Anyway, I don’t argue, it is something that could be improved.

>You cannot do this with IPv4 either. Routing has to work. It works for both IPv4 and In But if you are saying, you add 2-3-4 layers of NAT, this is just crazy.

Is it? I'm behind two layers of nat and everything works fine.

That NAT "does not work" is an old myth that certain people love to use. If you show it does work, their final reply is always: but inbound connections are hard.

I do not know who needs inbound connections to all of their devices in a corporate network, nor at home, since we solved that shit long time ago.

It only counts as working if you are ok with a giant pile of hacks and pain. Ever had to debug NAT-related SIP issues? Not fun. A lot of protocols fell out of favor, because they poorly interact with NAT (and stupid corporate firewall rules on the other hand so everything gets tunneled via https now..).

And wanting inbound connections is really not that strange a request. Maybe I want to host some website at home? How about a weather station/other IoT.. How about multiplayer gaming?

There are so many things that would benefit from being able to poke some holes in the firewall. With carrier grade NAT becoming more and more common you can forget about that, since you have no control over their infrastructure to forward any ports.

Reply on news.ycombinator.com