IPv6 and Firewall traversal
Chuck Anderson
cra-WCkJK2/AXBA at public.gmane.org
Wed Mar 30 12:32:14 EDT 2011
On Wed, Mar 30, 2011 at 11:09:10AM -0400, Rob Hasselbaum wrote:
> On Wed, Mar 30, 2011 at 10:33 AM, Richard Pieri <Richard.Pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>wrote:
> > Anyone who relies on NAT for security has almost no network security (see:
> > source IP spoofing). NAT is not, and never has been, about security. It
> > exists to address the limited address space in IPv4 but it is not formally
> > part of IPv4. NAT is, ultimately, a clever hack used to link non-routable
> > networks to routable networks.
Agreed.
> > IPv6 removes this necessity. Thus, no NAT for IPv6. And hopefully there
> > never will be. IPv6 has link-local and site-local addressing, which
> > eliminates the need for segregating non-routable networks. This is built
> > into the specification. For everything else there is SPI.
Site-local addresses are deprecated:
http://tools.ietf.org/html/rfc3879
and replaced by Unique Local Addressing (ULA):
http://tools.ietf.org/html/rfc4193
> Agreed, NAT is not a required ingredient for an effective firewall. Apples
> and oranges. It does, however, provide source obfuscation for individual
> machines on a LAN, and there is some value in that. For example, I suspect
We have Privacy Addressing:
http://tools.ietf.org/html/rfc4941
> if it weren't for NAT, consumers would be paying their ISPs "per-node"
> connection fees. If things move in that direction in a mostly-IPv6 world, we
> could see a resurgence of NAT.
That is not supposed to happen. There is no reason for an ISP to hand
out IPv6 addresses one /128 at a time. They would be creating a
management nightmare for themselves and hurting their customers. The
latest recommendations on prefix sizing are here:
http://tools.ietf.org/html/rfc5375
http://tools.ietf.org/html/rfc6177
There is rough consensus that residential customers will be provided a
/56 prefix, enough for 256 /64 subnets, but there is no hard
requirement on that specific size.
More information about the Discuss
mailing list