On Mon, Jul 28, 2014 at 4:21 PM, Mark Martinec <mark.martinec+free...@ijs.si
> wrote:

> On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed <darr...@freebsd.org> wrote:
>>> [...]
>>> IPFilter 5 does IPv6 NAT.
>>> With the import of 5.1.2, map, rdr and rewrite rules will all work with
>>> IPv6 addresses.
>>> NAT66 is a specific implementation of IPv6 NAT behaviour.
> 2014-07-29 00:07 Kevin Oberman wrote:
>> And all IPv6 NAT is evil and should be cast into (demonic residence of
>> your
>> choosing) on sight!
>> NAT on IPv6 serves no useful purpose at all. It only serves to complicate
>> things and make clueless security officers happy. It adds zero security.
>> It
>> is a great example of people who assume that NAT is a security feature in
>> IPv4 (it's not) so it should also be in IPv6.
>> The problem is that this meme is so pervasive that even when people
>> understand that it is bad, they still insist on it because there will be
>> an
>> unchecked box on the security checklist for "All systems not pubic servers
>> are in RFC1918 space? -- YES   NO". The checklist item should be (usually)
>> "All systems behind a stateful firewall with an appropriate rule set? --
>> YES  NO" as it is a stateful firewall (which is mandatory for NAT that
>> provides all of the security.
>> I say "usually" because the major research lab where I worked ran without
>> a
>> firewall (and probably still does) and little, if any, NAT. It was tested
>> regularly by red teams hired by the feds and they never were able to
>> penetrate anything due to a very aggressive IDS/IPS system, but most
>> people
>> and companies should NOT go this route. I have IPv6 at home (Comcast) and
>> my router runs a stateful firewall with a rule set functionally the same
>> as
>> that used for IPv4 and that provides the protection needed.
>> So putting support for NAT66 or any IPv6 NAT into a firewall is just
>> making
>> things worse. Please don't do it!
>> --
>> R. Kevin Oberman, Network Engineer, Retired
>> E-mail: rkober...@gmail.com
> You are missing the point, we are talking about NAT64 (IPv6-only
> datacenter's
> path to a legacy world), and NPT66 (prefix transalation). I doubt anyone
> had
> a traditional NAT in mind.
> Consider a small site with uplinks to two service providers: it can use ULA
> internally and translate prefix on each uplink.
> Please see these short blogs:
> - To ULA or not to ULA, That’s the Question
>   http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html
> - I Say ULA, You Hear NAT
>   http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html
> - PA, PI or ULA IPv6 Address Space? It depends
>   http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html
> - Source IPv6 Address Selection Saves the Day
>   http://blog.ipspace.net/2014/01/source-ipv6-address-
> selection-saves-day.html
> Mark


No, all of the messages in the thread are specific about NAT66, not NPT66.
NPT66 may have real value. I hate it, but it may well be better than
alternatives. It addresses an issue I have had with many of the IPv6
purists. I do think some of the arguments for it are over-stated. Getting a
/48 is trivial, but getting it routed is not, so there is a real issue, but
it remains unclear how bit the issue really is. For most users,
multi-homing is fine, but not for servers. But smaller companies often farm
out their servers, so it's not an issue for them.

The one really significant issue I accept as real is the expansion of the
routing tables. While the IPv6 table is still fairly small (~17k) , it is
growing and has the potential to exceed the size of the IPv4 table (>500K)
which continues to grow due to deaggregation. For those not dealing with
backbone BGP, the issues include handling large numbers of prefixes and the
stability of routing tables (both RIBs and FIBs) with all of the churn
Since I have retired, I have not been involved in IPv6 implementation or
technical discussion, but I started dealing with it back in the 1990s and,
until I retired in 2011 I had the first computer (a DEC Alpha) that had an
ARIN assigned IPv6 address sitting under my desk, hershey.es.net. (No, it
was no longer in use.)

I also opposed ULA. While I understood the arguments in its favor, I have
still do not agree with them. I think ULA is simply a bad idea, but it is
there and we will have to deal with it... forever.
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to