[133228] in North American Network Operators' Group
Re: Pointer for documentation on actually delivering IPv6
daemon@ATHENA.MIT.EDU (Truman Boyes)
Tue Dec 7 01:26:04 2010
From: Truman Boyes <truman@suspicious.org>
In-Reply-To: <561818C9-A251-4AAA-B6D5-F5B2DAD5FD9D@delong.com>
Date: Tue, 7 Dec 2010 14:25:35 +0800
To: Owen DeLong <owen@delong.com>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 6 Dec 2010, at 11:07 PM, Owen DeLong wrote:
>=20
> On Dec 6, 2010, at 6:55 AM, Jared Mauch wrote:
>=20
>>=20
>> On Dec 6, 2010, at 8:35 AM, Jeff Johnstone wrote:
>>=20
>>> Speaking of IPV6 security, is there any movement towards any open =
source
>>> IPV6 firewall solutions for the consumer / small business?
>>>=20
>>> Almost all the info I've managed to find to date indicates no =
support, nor
>>> any planned support in upcoming releases.
>>>=20
>>> Any info would be helpful.
>>=20
>> Honestly (and I'm sure some IPv6 folks will want me injured as a =
result) there should be some '1918-like' space allocated for the =
corporate guys who "don't get it", so they can nat everyone through a =
single /128. It would make life easier for them and quite possibly be a =
large item in pushing ipv6 deployment in the enterprise.
>>=20
> Yes... Those of us who would like to see sanity return to the internet =
would prefer to have you lynched for such heresy. ;-)
>=20
> 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.
You can of course use Unique Local IPv6 Unicast Addresses internally. =
(RFC 4193). And if you wanted you could NAT66. But, this is not an ideal =
way to design a network. The benefit of RFC1918 addresses is that you =
can easily know the perimeter of your global reachability. You can =
achieve the same with public IPv6 by *knowing* your security policy. =
Public addresses on internal infrastructure are quite normal.=20
>> I don't see our corporate IT guys that number stuff in 1918 space =
wanting to put hosts on 'real' ips. The chances for unintended routing =
are enough to make them say that v6 is actually a security risk vs =
security enabler is my suspicion.
>>=20
> There are multiple easy ways to solve this problem that don't require =
the use of NAT or the damage that comes with it.
>=20
> 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.
>=20
> It's trivial to implement an IPv6 default-deny-inbound stateful =
inspection policy that provides exactly the same security
> model as is afforded by the current NAT box in IPv4 without mangling =
the packet headers. The rest is superstition.
> Admittedly, superstition is powerful among IT professionals, =
especially in the enterprise world. 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.
>=20
> 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.
>=20
> Owen
I agree with Owen. You could NAT66, but seriously, why bother with all =
that headache in implementing v6 on your hosts and then putting all =
sessions through NAT. IPv6 security policy would be more explicit =
security than a NAT perimeter.=20
Truman
