the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed Apr 28 13:37:04 UTC 2010


On Tue, 27 Apr 2010 14:29:50 -0400
Dave Israel <davei at otd.com> wrote:

> On 4/27/2010 1:36 PM, Andy Davidson wrote:
> > On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
> >   
> >>> Did you use Yahoo IM, AIM, or Skype?
> >>>       
> >> Yes, yes, and yes.  Works fine.
> >>     
> > What about every other service/protocol that users use today, 
> > and might be invented tomorrow ?  Do & will they all work with 
> > NAT ?
> >   
> 
> Sure, I can invent a service/protocol that doesn't work with NAT.  While
> I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an
> architectures using less than 256 bits of memory addressing.  I bet
> it'll be popular!
> 
> 

One already exists. It's called DCCP, or Datagram Congestion Control
Protocol - it's like UDP with congestion management. It'd be great to
use for Video and Voip, which could then vary the codec parameters to
suit congestion should it occur. Shame NAT has stopped it being widely
deployed.

SCTP could be used to perform peer to peer IM and file transfers, where
the file transfer takes place within the existing SCTP connection,
rather than having to establish a separate connection. Shame NAT has
stopped it being widely deployed.

> > Do many others work as well or act reliably through NAT ?
> >   
> 
> Yes, nearly everything that end users use works great through NAT,
> because end users are often behind NAT and for a service to be popular,
> it has to be NAT-friendly.  Protocols that are not NAT friendly and yet
> survive are generally LAN applications that are resting on their
> NAT-unferiendliness and calling it security.
> 
> > Will it stop or hamper the innovation of new services on the
> > internet ?
> >   
> 
> Nope.
> 
> > The answer to these questions isn't a good one for users, so
> > as the community that are best placed to defend service quality
> > and innovation by preserving the end to end principal, it is 
> > our responsibility to defend it to the best of our ability.
> >   
> 
> The end to end principle only helps service quality and innovation when
> the services are built on an end to end model.  In a client-server world
> where addresses only identify groups of endpoints and individual
> identification is done at higher layers (which is what the ipv4+NAT
> Internet is looking like), end to endness is an anomaly, not the norm.
> 
> > So get busy - v6 awareness, availability and abundancy are
> > overdue for our end users.
> >   
> 
> Nearly all of the end users don't give a rat's hindquarters about ipv6. 
> It gives them nothing they know that they want.  Meanwhile, those who do
> know they want it are getting used to working around it, using PAT
> tricks and STUN services.  Should people *have* to use those services? 
> No.  But there's so many other things that we shouldn't have to do, but
> we do anyway because that's how it works, that these NAT-circumvention
> tricks are not a dealbreaker.
> 
> Meanwhile, the NATification of the Internet continuously increases the
> contrast between services (with real addresses) and clients (with shared
> addresses).  Over time, this differentiation will increase and become
> more and more a standard (a de facto one if not an actual codified
> one.)  Clients will have shared, ephemeral addresses, and services will
> have stable ones.  This helps ensure that clients cannot generally
> communicate without a facilitating service, and every transaction will
> then have a middleman, somebody you have to pay somehow to get your
> services.  You may pay in cash, by watching commercials, by sacrificing
> personal information, or by submitting your communciations to analysis
> by others, but somehow, you will pay.  The vast majority of users won't
> care; they communicate that way now, and it does not bother them much. 
> It's only those few who want to communicate without paying, in time,
> money, or privacy, or to communicate in ways other than the standard
> protocols, who will really suffer.  And their complaints will have to
> fight against the voice of those who will say, well, if you make it end
> to end, then businesses lose money, and people will be able to share
> files again and violate copyrights, and all these things will cost jobs
> and tax dollars, etc, etc.
> 
> If you want to avoid that future, I strongly suggest you deploy ipv6 and
> pressure others to do the same.  But you're going to need to use valid
> arguments, about privacy and protection from the deprecations of
> unscrupulous middlemen, instead of insisting that the Internet will
> break down and die and locusts will descend from the heavens and eat our
> first born if we don't.
> 
> -Dave
> 
> 




More information about the NANOG mailing list