[arin-ppml] An article of interest to the community....

[Mike Burns]

Hi Paul,

80 is not the only port.
Remember port 21's problem with port 20?
That screwed up Nat right from the getgo, but how long did it take for 
passive ftp to appear?
I use multi-level Nat every day and I manipulate ports which carry http, 
https, Radius, ftp, voip, vnc, Xbox, MagicJack, Netflix, Skype, etc, etc. 
Tcp and udp. Every day.
.
Rendezous servers allow for Nat traversal while at the same time providing 
access security. Stun and SIP work and UpNP also works.

I don't know how closely bound bandwidth growth is to Moore's Law, but the 
market has decided that including "state" in the form of  Nat is an 
acceptable practice. In fact Nat has been at the edges doing stateful stuff 
for 15 years, and Cisco and Juniper have big iron boxes for CGN.

The documents I posted earlier were written by people whose understanding of 
this issue is not limited to the crippled web-centric mindset you 
erroneously apply to me. Like your speculator commentary, it's an ad hominem 
which does not advance your position.

What applications is Nat holding back?

Regards,

Mike




----- Original Message ----- 
From: "Paul Vixie" <paul at redbarn.org>
To: <arin-ppml at arin.net>
Sent: Tuesday, August 30, 2011 8:48 PM
Subject: Re: [arin-ppml] An article of interest to the community....


> On Tue, 30 Aug 2011 16:06:11 -0400
> "Mike Burns" <mike at nationwideinc.com> wrote:
>
>> ...
>> And this is in answer to the question posed by Mr. Vixie, which
>> postulated a no-option endpoint at IPv6.
>
> looking at that again:
>
> On Tue, 30 Aug 2011 12:01:14 -0400
> "Mike Burns" <mike at nationwideinc.com> wrote:
>
>> ...
>> As to your issue about what happens after IPv4 is at its best and
>> highest use, I have given this some thought over the years.
>> Have you considered that a robust trading market and CGN might buy us
>> enough time to come up with some kind of backward compatible
>> successor protocol to IPv4?
>
> yes, i considered (and rejected) this approach back in the late 1990's.
>
>> Proposals for these kind of solutions have been made in IETF but are
>> routinely ignored.
>
> there are several reasons why this kind of solution is routinely
> ignored when it comes up in the IETF or elsewhere.  first, because the
> internet's initial success depended on a stateless core, and most of us
> assume that to make traffic capacity scale with transistor density we
> will have to continue keeping state out of the core.  the internet
> core is packet based even if the web we've built atop the
> internet appears to be virtual circuit based (tcp/80).  second, because
> the transition from ipv4 to ipv6 is already very difficult and most of
> us know that leaving basic design questions open would make the
> transition even more difficult.  (we now know better ways to do secure
> dns than the current dnssec design; we now know better ways to do
> packet switched networking than the current ipv6 design; but we have to
> stop designing and stop building at some point, not optimize forever
> and get nothing.)
>
>> To my mind there is room in the IPv4 header to expand the effective
>> address space.
>> GGN does this effectively and largely transparently today using the
>> additional room in the  port number part of the header.
>> Every TCP connection uses IP+port, and we have 65,000 ports per IPv4
>> address.
>
> if the internet were not older and larger than the web, then your
> web-centric mental image as outlined above might be a realistic way
> forward.  notwithstanding the fact that a lot of us build a lot of
> services on top of tcp/80 since it's a fairly reliable serial channel
> that works even in hotel rooms, the internet also has to support packet
> based services that do not map well to virtual circuit style mechanisms
> like tcp.
>
>> The dual-stack transition is a failure, it is time to recognize that
>> the lack of an economic motive for IPv6 created a situation where
>> dual-stack was doomed.
>
> disagreed.
>
>> And we have gotten pretty darn good at traversing NAT already,
>> despite the doomsayers.
>
> also disagreed.  what "we've" done is hold back some kinds of
> applications altogether because of NAT, and increase both the
> development and operating costs of other applications because of NAT.
> i am treating NAT as a transitory economy-wide externalized cost, not
> as an inevitable part of the future of all IP networking.
>
>> It does not further your position to openly wonder whether those who
>> "complain" are "hoarders and speculators".
>
> noted.  however, the thing you're complaining about here isn't the
> position i was describing.  if you only wanted to sell "web access"
> rather than "internet access" then you can live with NAT and you'd have
> no oar in the water wrt IPv6.
> -- 
> Paul Vixie
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.