Re: IPv6 NAT?

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

 



On Thu, 2008-02-14 at 17:12 -0500, Dan York wrote:
> 
> On Feb 14, 2008, at 4:16 PM, Iljitsch van Beijnum wrote:
> 
> > On 14 feb 2008, at 21:49, Florian Weimer wrote:
> > 
> > 
> > > The prevailing assumption is that IPv6 end nodes will be globally
> > > addressable for practical purporses.  I think this is a very
> > > unlikely
> > > outcome.
> > 
> > 
> > Are you saying that there will be IPv6 NAT?
> 
> 
> Absolutely.  100% guaranteed that some organizations out there will
> continue to use NAT even with IPv6.  
> 
> 
> In my opinion, anyone who thinks otherwise does not understand how
> wedded corporate enterprises are to NAT and how NAT will only be
> removed when the keyboard is pulled from the cold, dead fingers of the
> last remaining sysadmins.
> 
> 
> Instead of the "private addresses" of IPv4 as defined in RFC1918 it
> will simply be the "Unique Local Addresses" of IPv6 as defined in
> RFC4193 - http://tools.ietf.org/rfcmarkup?doc=rfc4193  Instead of
> starting with 10. (or 192. or 172.), the address block will start with
> FC00... but the end result will be the same.  (And look, this time
> around it even has it's own TLA ("ULA")!)
> 
> 
> Corporate enterprises love NAT for several reasons. Here are two:
> 
> 
> 1. "SECURITY" - There is this belief that an organization is more
> secure by hiding the topology of their entire network behind a few
> public addresses that can be locked down and secured by appropriate
> firewalls and gateways.  IT staff don't give a darn about our glorious
> visions of end-to-end connectivity... they only care about "securing
> the perimeter" and many (most?) see NAT as one way of doing that.  We
> can argue endlessly that this may simply be an illusion (delusion?) on
> their part and that NAT really doesn't provide real security, but from
> what I have seen it *is* the prevailing view out there within the IT
> community.
> 
> 
> 2. CONTROL - Organizations like the control that comes with defining
> their own address ranges.  They don't need to obtain permission from
> anyone to number certain networks.  They just do it.  Simple. Easy.
>  They can create a master plan across all their locations on their
> WAN.  As they add more networks through growth (either new
> installations or through mergers/acquisitions), they can simply assign
> those new networks numbering blocks out of their master plan.  In
> fact, I would argue that ULA addressing (there I go with that TLA!)
> makes that even nicer since the recommended means of generation of the
> ULA block (in RFC4193) *should* wind up reducing the conflicts we have
> today where merging entities are both using identical sections of the
> RFC1918 10.x block. In theory the networks should be even easier to
> merge.  Likewise, if a network gets split off from another one, it may
> be able to be merged into its new owner very easily (and without
> renumbering) via ULA addressing.
> 
> 
> In this last instance, think of what happens if I'm using assigned
> IPv6 addresses from Company A and now my network is sold to Company B.
> Now I have to renumber my entire network to use Company B's assigned
> IPv6 addresses.  If I just use ULA addressing I don't have to renumber
> (unless by some freak chance I happen to be using the same ULA block
> that some other network in Company A is using).
> 
> 
> So yes, I absolutely think that NAT will continue in IPv6.  Corporate
> enterprises are comfortable with it and expect it.  That's the
> reality.

All that said, what happens when organizations would like to use multihoming?
In that case NATs create problems as flows have to use the same
exit/entry point, and when one of the connections breaks all the flows
going through the given connection will also be broken?

How is this problem solved in current IPv4 networks?

Thanks,
Stjepan

_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]