Text 12906, 130 rader
Skriven 2010-12-04 14:49:26 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av mark lewis (1:3634/12.0)
Ärende: Firewalls and routers
=============================
Hello mark,

On Friday December 03 2010 13:12, you wrote to me:

 MvdV>>> NAT is a kludge to let more than one device share a public IP
 MvdV>>> address.

 ml>> i beg to differ that it is a kludge...

 MvdV>> Call it what you want, but a kludge by another name is still a
 MvdV>> kludge.

 ml> you mean like all the control lines that may appear in FTN style
 ml> messages?? ;)

Call them control lines if you want but current practise is to call them kludge
lines. It is called a kludge because the proper place for control information
is the message header. Unfortunately TJ et al did not have the foresight to
provide for a variable length header, or at least a header extension. They
opted for a fixed length header with insufficient space for future needs. And
so we use kludge lines for extra control information...

Call it what you want, but a kludge it is.

 ml>> perhaps you are not aware of the documents that RFC1918 stems
 ml>> from? check RFC1597 dated March 1994 ;)

 MvdV>> I am aware of the original reasons for introducing private
 MvdV>> address space. It had nothing to do with NAT.

 ml> of course not... why would you or anything think it ever did???

We were discussing NAT. I called it a kludge, you expressed disagreement
without clearification. Your wording suggested superior knowledge that you did
not want to share directly, but you pointed me to said RFC, suggesting I might
find enlightment there...

 MvdV>> I am also aware of the difference between active and passive FTP
 MvdV>> and how that relates to firewalls. Note: firewalls, not NAT.

 ml> yeah, your point is??

My point is that you are raising a smoke sceen. You suggest you have superior
knowledge but refuse to share it. When challenged you refer to some documents
that have no direct bearing on the matter at hand.

 ml> is this something that i don't already know after all these years of
 ml> installing, configuring and managing networks and networked
 ml> computers???

I do not know what you know because you never give clear answers. They are
always hidden in the mist, suggesting a lot, but telling nothing. And when push
comes to shove, you tell us that we have to find out for ourselves.

Well, it was only 25 years ago that I first dealt with packet switched
networks, so who am I to question your authority? :-(

 MvdV>> Some call it a work around, but I call it a kludge because it
 MvdV>> does not address the basic problem and creates problems of its
 MvdV>> own.

 ml> i simply call it current operating standards and do not see anything
 ml> wrong with it...

I agree that it is current operating practise, but that does not mean it is not
a kludge amf that there is nothing wrong with it.

 ml> indeed, it should have been implemented from the start and all
 ml> internal networks, corporate/SOHO/educational/etc, should have been
 ml> using RFC1918 addressing from the beginning with one public IPv4 WAN
 ml> address for internet access...

I totally disagree. Full end to end connectivity for all connected devices - or
at least the possibility to enable it - has always been the way the InterNet
was designed. NAT is a kludge that breaks that and it requires a lot more
kludging to get certain things to work through NAT.

 ml> there are numerous other things that are current practise that should
 ml> also have been SOP from the beginning...

Perhaps, but that is not what we were discussing.

 MvdV>> The basic problem is that the InterNet has grown too big to to
 MvdV>> make it work as designed with 32 bit addresses. THAT is the
 MvdV>> problems that should have been addressed ten years ago at the
 MvdV>> latest by the powers that be, instead of waiting until the well
 MvdV>> has almost run dry and having to introduce IPv6 in a frenzy..

 ml> and IPv6 is going to solve what problem?

The shortage of globally routable unique addresses of course! Have you not been
following what is going on regarding the IPv4 address depletion? Well, here is
news for you: IANA will run out of its pool of unallocated IP4 addresses
sometime between now and May next year. It all depends on when APNIC requests
two more blocks. That can happen tomorrow or it can happen next year. But it
certainly will happen before June, because that is when *their* pool runs dry.

 ml> is switching to a 64bit unsigned number from a 32bit signed number for
 ml> the computer's "seconds since the epoch" really going to solve the
 ml> problem of running out of storage space?

Yes, it does.

 ml> no, it doesn't and won't... it only delays the inevitible...

You seem to have no idea of exponential growth. A 32 bit signed number for the
seconds clock - effectively a 31 bit counter - can cover a span of 68 years. 40
have already ticked away, so some among us will surely live to see it overflow
in 2038.

A 64 bit clock OTOH, covers 5.8 x 10 exp 11 years. About 50 times the estimated
life of the universe. That clock overflowing is so far in the future that it
becomes meaningless. We do not know how the universe will look like by that
time and it is subject of some interesting speculation, but all models predict
that it will not look enough to what it looks like now to sustain life as we
know it. For all intents and purposes extending to 64 bits DOES solve the clock
overflow problem.

 ml> IP addressing is in the same quandry and likely will remain in this
 ml> quandry for many years to come...

No. The IPv6 address space, which BTW is 128 bits wide, not 64 bits, is so
large that mankind will not see it run out. Not even if we manage to break the
light speed barrier and spread out over the galaxy.


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20070503
 * Origin: http://www.vlist.org (2:280/5555)