RE: IPv4 to IPv6 transition

[Ray Plzak <plzak at arin.net>]

The shortage of IPv4 addresses in developing countries in a red herring. All one has to do is apply for them from the RIR. Getting a service provider to route them is a different problem, especially when they profit from running your traffic through their NAT.

Ray

> -----Original Message-----
> From: philemon [mailto:philemon at drtvnet.cg]
> Sent: Tuesday, October 02, 2007 6:40 AM
> To: Hannes Tschofenig; Keith Moore
> Cc: Stephen Sprunk; ietf at ietf.org; Paul Hoffman
> Subject: Re: IPv4 to IPv6 transition
>
> Hi All
>
>
>
> Just an input about the NAT issue handled here. The 'war' against NAT
> is
> senseless before succeeding the one against IPv4. I mean, as far as the
> v4
> protocol runs on our networks, NAT will remain as a useful tool for
> those
> who need it, of course for specific applications. In developing
> countries
> for example where IPv6 entry is very slow -add to a scarcity of IPv4
> addresses- we are always using NAT, and are happy to do so as:
>
> 1- No enough IPv4 addresses
>
> 2-No need for the specific applications for those networks
>
> 3-No alternative solution currently 'in the hands'.
>
>
>
> Thanks
>
>
>
> Philemon
>
>
>
>
> ----- Original Message -----
> From: "Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>
> To: "Keith Moore" <moore at cs.utk.edu>
> Cc: "Stephen Sprunk" <stephen at sprunk.org>; <ietf at ietf.org>; "Paul
> Hoffman"
> <paul.hoffman at vpnc.org>
> Sent: Friday, July 13, 2007 9:11 PM
> Subject: Re: IPv4 to IPv6 transition
>
>
> > Hi Keith,
> >
> > Keith Moore wrote:
> >>> Most application protocols work just fine behind NAT. FTP works
> with
> >>> an ugly work-around. The main protocol that breaks down is SIP.
> >>>
> >>>
> >>
> >> there are a couple of problems with this analysis:
> >>
> >> one is that it considers only application protocols that are in
> >> widespread use.  there are lots of applications that are used by
> limited
> >> communities that are nevertheless important.
> >
> > Namely?
> >
> >
> >>   and of course, since NATs
> >> are so pervasive, most of the applications that are in widespread
> use
> >> have been made to work with NAT (often at tremendous expense, and
> >> reduced reliability).
> >>
> > Could you explain the tremendous expense a bit more?
> >
> >
> >> another problem is that it only considers current applications.  a
> big
> >> part of the problem with NAT is that it inhibFrom ietf-bounces at ietf.org Tue Oct 02 08:18:46 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IcgZD-00035D-M8; Tue, 02 Oct 2007 08:09:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IcgZB-00034x-IW
	for ietf at ietf.org; Tue, 02 Oct 2007 08:09:33 -0400
Received: from aharp.ittns.northwestern.edu ([129.105.153.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcgZ1-0007AP-EV
	for ietf at ietf.org; Tue, 02 Oct 2007 08:09:29 -0400
Received: from dsl017-022-071.chi1.dsl.speakeasy.net (aharp [127.0.0.1])
	by aharp.ittns.northwestern.edu (smtpd) with SMTP id 16C20136C82
	for <ietf at ietf.org>; Tue,  2 Oct 2007 07:09:03 -0500 (CDT)
Date: Tue, 2 Oct 2007 07:09:02 -0500
From: John Kristoff <jtk at northwestern.edu>
To: ietf at ietf.org
In-Reply-To: <7494AF81-70CE-4F94-83A1-537401276949 at tcb.net>
References: <200710020741.l927fhWW067952 at drugs.dv.isc.org>
	<7494AF81-70CE-4F94-83A1-537401276949 at tcb.net>
X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20071002120903.16C20136C82 at aharp.ittns.northwestern.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: Re: [secdir] secdir review of
 draft-ietf-dnsop-reflectors-are-evil-04.txt
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

On Tue, 2 Oct 2007 01:48:36 -0600
Danny McPherson <danny at tcb.net> wrote:

> Again, any pointers empirical data along these lines would
> be appreciated.

I said this awhile back:

  <http://www.merit.edu/mail.archives/nanog/msg02196.html>

  "As a datapoint I ran some tests against a reasonably diverse and
  sizeable TLD zone I work with in another forum.  I queried the name
  servers listed in the parent to see if I could successfuly query
  them for their corresponding domain name they are configured for
  using TCP.  Out of about 9,300 unique name servers I failed to
  receive any answer from about 1700 of them.  That is a bit more
  than an 18% failure rate."

I think I overcompensated as I later found what looked like BIND 8
servers being unresponsive for multiple TCP queries in queue.  I let
the numbers stay, since the percentage of those servers were fairly
small and, well, they were BIND 8 and probably have other problems
anyway. :)

John

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf