Building simplicidade.org: notes, projects, and occasional rants

More about NAT

I’m reading the meeting notes of the “behave” BOF at the latest IETF meeting.

There are some remarks that make me nervous. There is a belief that IPv6 will end the need for NAT:

NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms (e.g. 6to4).

Maybe I’m reading this wrong, but I interpret this as: When IPv6 comes, you wont need NAT.

If that’s correct, then I’l be the first to say it: when IPv6 comes, I’ll sill want to use NAT. I don’t use NAT because of IPv4 address space shortage, or lack of features in IPv4. I use NAT because I don’t want the trouble of configuring a firewall in my workstation, and I prefer to have a smallish dedicated router doing it for me. It feels safer. Yes, it is very subjective.

One source of “nat is evil” seems to be rfc 3424. I read it, and I understand the problems they mention there.The third point of my wish list mentioned here seems to be very difficult.

There are also a lot of security considerations about allowing all these incoming connections, but I think that having a protocol to request such communications to happen only make it easier to block/audit/validate those requests.

Also the reliability of the communication is lessen in the sense that now the NAT box has to keep state about it, and if that box fails the communication cannot be routed around to another exit point without going through another round of “expecting connection from X, give me a IP/port pretty please” with the new NAT box.

But as I read rfc 3424 I had to rethink my goals: I might not need a NAT environment but a very smart firewall between me and the world at large when IPv6 gets widespread adoption. The turning point is the C.2 paragraph in the above RFC:

C.2 Real World Home Network Example James Woodyatt provided the following scenario, based on current examples of home networking products: o the customer has existing Internet service from some broadband service provider, using e.g. a DSL line connected to an appliance that integrates a DSL modem with a NAT router/firewall. o these devices are sometimes packaged with automated provisioning firmware, so the customer may view them as part of what their ISP provides them. o later, the customer wants to use a host with only a wireless LAN interface, so they install a wireless access point that ships in its default configuration with NAT and a DHCP server enabled. o after this, the customer has a wired LAN in one private address realm and a wireless LAN in another private address realm. Furthermore, most customers probably have no idea what the phrase "address realm" means and shouldn't have to learn it. All they often know is that the printer server is inaccessible to the wireless laptop computer. (Why? Because the discovery protocol uses UDP multicast with TTL=1, but that's okay because any response would just be dropped by the NAT anyway, because there's no ALG.)

The last paragraph is what made me think: they want this to work in scenarios that, although very plausible, are also very clearly wrong :), and that lead me to the conclusion that I am thinking as a person who knows something about networking, at least enough to understand why this setup is wrong. A less technical person would not know.

Side-note: just yesterday I made this exact setup at my fathers house, and I disabled the DHCP and NAT from the Wireless Router. I also have the exact same setup at home.

I still think that the problems presented in the rfc can be solved, but until I write something about this, I’ll agree that the problem is complex, and that having IPv6, with an address to everybody or everything, its easier to implement and debug.

I just need a damn good firewall it seems.

This is fun.