ietf
[Top] [All Lists]

Re: NATs *ARE* evil!

2000-12-14 06:50:02

 Sean,


there were several interesting talks in the ietf plenary last night and 
i'd also like to respond

1/ randy's "woah, the DNS is bust" talk
        solution - put your named boot file on your web server and set
up robots.txt right

get the 15 or so most popular search engines to start pulling it

add an option to name resolution libraries to use http and
google/altavista/bla blah to lookup name/address bindings

(i.e. replace lookup with search and update with web crawl - you can
also make your dns update hapen faster by articficially hyping the
searches - yo ucan even include advertisements in the responses)

positive points
i) there are too many levels in the DNS server hierartchy - the name
hierarchy is important, but there is no reaso nto have multiple levels
in the server hierarchy - once upoj a time it was needed for some
scaling (localisation) of traffic - dns traffic is irrelvant compared with
web, so there's no problem doing it with 2 levels local/global - also,
the caching isnt working (as per randy and christian huitema's work)
anyhow so the localisdtion effects  merely add latency to lookups i
nthe current system

ii) there's lots of differt code for differ nt search enginees
this means we have a decent gene pool size compared with the DNS
server space where there's a good chance that like BGP, we are dead in
the water come the first new disease that we have no immunity too...

2/ NATs - 
i thought the comment was that there are too may ways of architecting NATs
which made it expensivce to buy one coz most the NAT box builders are
busy implementing all the varireities which makes them complex instead
of simple - two solutions
i) no ietf standards effort should continue after we have 3 approaches
to a problem - given NAT, IP tunnels and mpls have about 7, 14 and 143
different approaches, this is evidentially a good heuristic for
pruning pointless ietf wgs - of course those mpls watchers amongst us
may have noticed that this is happening there....
(note this doesn't invalidate my approach to fixing name serving about
since that is a single architecture buyt with lots of differnt
detaield implemtnation approaches)

3/ internationalisation - 
its clear that we are making great progress - the gentleman from the
ITU made it clear  in his speaking that are much better at
understanding christian huitema which is a great breakthrough...

4/ those of you who saw geoff huston's excellent 
"the bgp is hosed" talk at the routing area meeting, and its excerpted
comments in the plenary should be very afraid - i did a search on a
citation database on routing research - not to see what work has been
done recently on ways to solve inter-domain scaling, convergence and
correctness problems (though craig labovitz work is distinguised there
by both its quality, and its loneliness!), but also to see if there
was any indication that there was research in universities and
research labs that  was runnign at a level that might indicate clueful
people coming out of their grad schools ready to solve our problems -
there isnt. the research funding agents should be blamed for this:-)
(note that i am not talking about graph theoertizcians - more the
mit/berkeley/usc type research work that is done in a real world
context)

note that a major problem with the little wortk that is done is that
its not often done in realistic topologies - this is a problem with
ISPs who wont let people get at the data (or the traffic traces) so
with a few honourable exceptions, most the smart people trying to do
new stuff go on to other areas where there aren;t intractable barriers
to doig the experimental verficaition of the idea (e.g. transport:-)

 cheers

   jon

p.s. pierro de la francesca or vermeer make better gurus, but if you
want to read about routing and addressing and what we ccould have done
for ipng, i like paul francis' phd work:
(linked from
http://www.cs.ucl.ac.uk/staff/jon/paststudents.html
so you can see my bias:-)
it elegantly included some ideas from nimrod, but had some pragmatic
implementation decisions whioch made it fast and simple and flexible -
it emerged as pip, but was about 95% pruned out in the final v6
decisions...



<Prev in Thread] Current Thread [Next in Thread>