the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
Mark Smith
nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed Apr 28 21:29:12 UTC 2010
On Wed, 28 Apr 2010 08:44:41 -0700
Matthew Kaufman <matthew at matthew.at> wrote:
> Mark Smith wrote:
> > 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.
> >
> Mark, I think you made Dave's point perfectly. Sure, history will be
> littered with protocols developed after NAT was widespread but whose
> designers willfully ignored reality (often committees filled with a
> bunch of people who wanted to acknowledge reality and a few strong
> voices who want to pretend there's a world without NAT both now and in
> the IPv6 future). Many of these won't see wide deployment as a result.
>
I'm not people are understanding or know the true reality. NAT broke the
Internet's architecture, by turning IP from being a peer-to-peer
protocol into a master/slave one (think mainframes and dumb terminals).
Read RFC1958 if you don't understand what that means, specifically the
'end-to-end' principle part. IPv6's fundamental goal is to restore
end-to-end.
> You can add SIP and SDP to the list, as those were designed with an
> FTP-like belief that you can know your local address and send it around
> in the payload and expect the right thing to happen. (FTP at least had
> the excuse that it predated NAT deployment)... though SIP, for some
> inexplicable reason, has survived to make it to wide deployment anyway.
>
> Or you can run things like DCCP and SCTP encapsulated in UDP (works just
> fine), or design a new protocol that combines the best of DCCP and SCTP
> and DTLS and mix in some IP mobility and other features and deploy it to
> almost every Internet host (what I did... the protocol is RTMFP and it
> is in every copy of Flash Player since version 10.0), or design a new
> protocol for your application which does what DCCP and DTLS do only for
> your own widely deployed application (as the Skype folks did). All of
> these are excellent approaches for having something which *actually
> works*, though impefectly as the backlash against NATs in groups such as
> the IETF has lead to a big lack of standards around how they should work.
>
> Either applications learn to deal with NAT, in which case they thrive on
> both the heavily-NATed still-mostly-IPv4 Internet of the future *or* the
> has-NAT mostly-IPv6 Internet of the future (a great way to hedge your
> bets if you're writing protocols and applications)... or they don't
> learn to deal with NAT, in which case they don't work on todays IPv4
> Internet *and* they won't work on the heavily-NATed still-mostly-IPv4
> Internet of one possible future *or* the has-NAT mostly-IPv6 Internet of
> the future. Those won't be nearly as popular.
>
> And in case you don't have handy a short list of why the IPv6 Internet
> will be filled with NAT, I'll give you three items to start with:
>
> 1. SOX, HIPPA, and other audit checklist compliance currently requires
> NAT for (theoretical) fail-closed and topology hiding. If IPv6 NAT
> exists, this requirement may not go away.
> 2. There will be a requirement for client hosts which have IPv6 SLAAC
> implementations that expose their MAC address in the low address bits to
> have those bits hidden from the outside Internet.
> 3. Organizations not large enough to qualify for (or who don't wish to
> bother with) PI space will deploy NAT so as to avoid internal
> renumbering of things which must have static addresses (Intranet
> servers, DNS resolvers, etc.). This is because the IPv6 future where
> every LAN is carrying multiple PA addresses to every host wasn't
> sufficiently well designed for it to actually work for either the
> multihoming case or the interior-network/outside-Internet case.
>
> The good news is that it might be sufficient to do pure NAT and not
> NAPT, and it might be possible still to get some good standards around
> how these devices should behave... both of which aren't happening for
> the IPv4 Internet, unfortunately.
>
> Matthew Kaufman
>
More information about the NANOG
mailing list