Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 and Firewall traversal



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.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org