Addressing plan exercise for our IPv6 course

Thu Jul 29 10:46:29 UTC 2010

On Tue, 27 Jul 2010 12:34:40 -0700
Owen DeLong <owen at delong.com> wrote:

> 
> On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote:
> 
> > Please see comments inline.
> > 
> > 
> > On 7/22/10 10:13 PM, "Owen DeLong" <owen at delong.com> wrote:
> > 
> >> In all reality:
> >> 
> >> 1.      NAT has nothing to do with security. Stateful inspection provides
> >>        security, NAT just mangles addresses.
> > Of course, the problem is that there are millions of customers that believe
> > that NAT == security. This needs to change.
> >> 
> >> 2.      In the places where NAT works, it does so at a terrible cost. It
> >>        breaks a number of things, and, applications like Skype are
> >>        incredibly more complex pieces of code in order to solve NAT
> >>        traversal.
> > 
> > I look at this as water under the bridge. Yep, it was complicated code and
> > now it works. I can run bittorrent just fine beyond an Apple wireless router
> > and I did nothing to make that work. Micro-torrent just communicates with
> > the router to make the port available.
> > 
> It's only water under the bridge for IPv4. If we start putting NAT66 into play,
> it will be the same thing all over again.
> 
> Additionally, it's only water under the bridge for existing applications. Each
> new application seems to go through the same exercise because for some
> reason, no two NAT gateways seem to have exactly the same traversal
> requirements and no two applications seem to implement the same set
> of traversal code.
> 

What is worse about that is that we networking people have ended up
shifting the cost of fixing our problem onto the application
developers and onto the application users. Because we don't provide
end-to-end visibility between peers on the Internet ("Internet
transparency" - see RFC4924), application developers have to try to
develop methods of doing that themselves. As you've said, this creates
additional application complexity, additional bugs, and duplicate
functionality between different applications, all at the application
layer. (HTTP has become the de facto substrate protocol of the Internet
because firewalls permit it, and client server communication has become
the de facto communications method for applications that would truly
benefit from peer-to-peer communications (i.e. more scalable, more
available), because client server overcomes the lack of global
reachability NAT creates))

Who pays this additional application development cost? Everybody,
including us networking people, because we also use applications
too. We get code that is possibly more buggy because it is more complex,
written by people who are usually not networking code experts. We might
miss out on better user interfaces or less buggy code that's there to
do what the application's purpose is, because that time was instead
spent on developing network layer work arounds. 

It seems to me that the best place to solve problems is whether they
exist or where they're caused. Those solutions usually solve the
problem properly, and commonly are also the cheapest way to solve it.

The network layer is where these problems exist, and that's where they
should be solved. We should use IPv6 to restore Internet transparency,
so that application developers don't have to do it for us - again.
We'll end up with a better and simpler Internet to operate, and better
and/or cheaper applications.

Regards,
Mark.

> > 
> >> The elimination of NAT is one of the greatest features of IPv6.
> >> 
> >> Most customers don't know or care what NAT is and wouldn't know the
> >> difference between a NAT firewall and a stateful inspection firewall.
> >> 
> >> I do think that people will get rid of the NAT box by and large, or, at least
> >> in IPv6, the box won't be NATing.
> >> 
> >> Whether or not they NAT it, it's still better to give the customer enough
> >> addresses that they don't HAVE to NAT.
> >> 
> >> Owen
> >> 
> > 
> > Of course, no disagreement there. The real challenge is going to be
> > education of customers so that they can actually configure a firewall policy
> > to protect their now-suddenly-addressable-on-the-Internet home network. I
> > would love to see how SOHO vendors are going to address this.
> > 
> Not so much... SOHO gateways should implement stateful inspection
> with the same default policy a NAT box provides today...
> 
> 1.	Outbound packets create a state table entry.
> 2.	Inbound packets are only forwarded if they match an existing
> 	state table entry.
> 
> Pretty simple, actually.
> 
> Owen
> 
> 