Re: using "reserved" IPv6 space

[Seth Mos <seth.mos () dds nl>]

Hi,

Op 16 jul 2012, om 18:34 heeft valdis.kletnieks () vt edu het volgende geschreven:

> On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
> > -------That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
> > if there weren't enough customers asking for it. Are all the customers naive?
> > I doubt it. They have their reasons. I agree with your "purist" definition and
> > did not say I was using it. My point is that vendors are still rolling out base
> > line features even today.
>
> Sorry to tell you this, but the customers *are* naive and asking for stupid
> stuff. They think they need NAT under IPv6 because they suffered with it in
> IPv4 due to addressing issues or a (totally percieved) security benefit (said
> benefit being *entirely* based on the fact that once you get NAT working, you
> can build a stateful firewall for essentially free).  The address crunch is
> gone, and stateful firewalls exist, so there's no *real* reason to keep
> pounding your head against the wall other than "we've been doing it for 15
> years".

To highlight what the current NAT66 is useful for, it's a RFC for Network Prefix translation. It has nothing do with 
obfuscation or hiding the network anymore. It's current application is multihoming for the poor.

Example:
You have a Cable and a DSL, they both provide IPv6 and you want to provide failover. You then use ULA or one of the 
Global Addresses on the LAN network, and set up NAT66 mappings for the secondary WAN, or both if you are using ULA.

This will not hide *anything* as your machines will now be *visible* on 2 global prefixes at the same time. And yes, 
you still use the stateful firewall rules on each WAN for the incoming traffic. And you can redirect traffic as needed 
out each WAN. It's the closest thing to the existing Dual WAN that current routers support.

Also note that this also works fine with 2 IPv6 tunnels. Bind each tunnel to a WAN and you have the same failover for 
IPv6 as IPv4.

Cheers,

Seth