Pointer for documentation on actually delivering IPv6

Mon Dec 6 15:49:25 UTC 2010

On 12/6/2010 9:07 AM, Owen DeLong wrote:
> Seriously, though, you're welcome to use fd00::/8 for exactly that
> purpose. The problem is that you (and hopefully it stays this way)
> won't have much luck finding a vendor that will provide the NAT for
> you to do it with.
>

Corporate IT community *expects* a broken Internet. They aren't doing 
their jobs if they haven't broken everything and it's dog. Vendors will 
provide what their customers demand, so there will be NAT on the 
corporate firewalls.

What I don't want to see is NAT on home routers.

> There are multiple easy ways to solve this problem that don't require
> the use of NAT or the damage that comes with it.
>

Corporations thrive on damaging traffic, and many prefer NAT. Every 
instinct in their body screams that removing NAT is bad, and you won't 
win that argument.

> First, let's clarify things a bit. I don't think unintended routing
> is what concerns your IT guys. Afterall, even with the NAT box today,
> there's routing from the outside to the inside. It's just controlled
> by stateful inspection.

1918 space generally isn't routed to their firewall from the outside, so 
some mistakes that leave the inside vulnerable are actually somewhat 
protected by using 1918 space which isn't routed. It's a limited 
scenario, but what every corp IT guy I know points to.

> So strong that people on this very list who I generally respect and
> consider to be good competent professionals tell me that I'm flat
> out wrong about it.

It's not superstition that the IP addresses assigned to the inside 
aren't routed from the upstream to to outside interface of the firewall. 
ie, when NAT/SPI is broken, the traffic itself breaks, not a sudden "We 
are wide open!" event.

This is not about *proper* security. It is about the extra gain when 
someone screws up and kills the firewall ruleset. In a 1 to 1 NAT 
environment, losing your SPI would be bad. In a 1 to N NAT environment, 
a majority of the machines can never be reached if the SPI/NAT engine 
dies (unless the upstream suddenly adds a 1918 route to reach them).

>
> However, not one of them has been able to produce an argument that
> actually stands up to scrutiny. The closest they can come is what
> happens when someone misconfigures something. However, I've always
> been able to show that it's equally easy to make fatal
> misconfigurations on the NAT box with just as dire consequences.

It is possible, yes. However, in the case of an overloaded NAT without 
port forwarding, there is no way to reach the backend hosts unless the 
upstream adds a route to the 1918 space behind the firewall. This is 
what people object to. A single route. That's it. If NAT doesn't work, 
the route is required. Without NAT, if your SPI doesn't work, the route 
is already there and you may have defaulted open.

So does NAT add to security? Yes; just not very much. It covers one 
condition; that is all. For that condition, you have a huge amount of 
service breakage. For a corporate network, this may be perfectly fine 
and acceptable.

Jack