North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Where NAT disenfranchises the end-user ...

  • From: Roeland Meyer
  • Date: Fri Sep 07 16:10:26 2001

|> From: Jim Shankland [mailto:[email protected]]
|> Sent: Friday, September 07, 2001 12:35 PM
|> Roeland Meyer <[email protected]> writes:
|> > You've just described a NAT proxy daemon. I've spent years 
|> trying to write
|> > one. If you are that good, send code. Or better yet, send it to
|> > The fundimental reason that you can't 
|> write one is that
|> > it requires a whole other protocol that 1) deosn't exist, 2)Isn't
|> > implemented, 3)Violates more than one of Dykstra's laws.
|> Don't mean to nitpick, but I was describing no such thing.  I was
|> suggesting the development of a protocol.  Saying that can't be done
|> because the protocol "1) deosn't exist, 2)Isn't implemented" seems
|> a little circular :-).  Don't know which of Dijkstra's laws 
|> that might
|> violate, either (except maybe "Don't misspell my name" :-)).

I'm also dutch and should know better. However, neither can I type, as the
quoted portion clearly shows. .. cna't spell, can't type, I must write code
<g>. lint will save me.

I'm also too terse for my own good, sometimes. Item 2 is looking forward to
deployment. Adoption will be supremely difficult and unless universally
adopted, it won't fly. It's a flash cut-over scenario with disparate
implementors. Success is estimated at around 0.001%, in such cases.

The law I am thinking of is the one where the application can't tell where
the failure is until it fails. It is fundimentally unpredictable.

|> The argument, roughly, is that there is a small set of operations
|> (identifying an <ipaddr:port> tuple in a network-portable way, and
|> dynamically allocating a new port to an application, are two 
|> that come
|> to my mind) that make NAT and firewalls difficult for games, 
|> streaming
|> audio/video, etc.; and that providing a standard protocol for these
|> operations would make building such applications, and having them
|> interoperate well with NATs and firewalls, much easier.
|> I'm not convinced this argument is correct, though it passes the
|> first-tier plausibility test in my mind.  I just thought I'd float
|> the trial balloon.

The problem is in how to deal with the legacy. Also, most FW builders don't
want to give out any clue to a potential attacker, so they silently discard
the packets. In this case, how is a feedback mechanism supposed to work?