Pointer for documentation on actually delivering IPv6

Tue Dec 7 06:25:35 UTC 2010

On 6 Dec 2010, at 11:07 PM, Owen DeLong wrote:

> 
> On Dec 6, 2010, at 6:55 AM, Jared Mauch wrote:
> 
>> 
>> On Dec 6, 2010, at 8:35 AM, Jeff Johnstone wrote:
>> 
>>> Speaking of IPV6 security, is there any movement towards any open source
>>> IPV6 firewall solutions for the consumer / small business?
>>> 
>>> Almost all the info I've managed to find to date indicates no support, nor
>>> any planned support in upcoming releases.
>>> 
>>> Any info would be helpful.
>> 
>> 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.
>> 
> Yes... Those of us who would like to see sanity return to the internet would prefer to have you lynched for such heresy. ;-)
> 
> 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. 

>> 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.
>> 
> There are multiple easy ways to solve this problem that don't require the use of NAT or the damage that comes with it.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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. 

Truman