[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]



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



et>,
	Keith Moore <moore at cs.utk.edu>
Date: Tue, 2 Oct 2007 08:10:43 -0400
Thread-Topic: IPv4 to IPv6 transition
Thread-Index: AcgE4is8hUfLVlRSR2SX3lLsmAurkwACubwA
Message-ID: <FEA070315E40A3489D38398C35FE7BB2029322014C at EDAMAME.arin.net>
References: <20070701150230.090F5233CB at coconut.itojun.org><4687DA5A.5020407 at cs.utk.edu>
	<01d901c7c56c$b1d33fe0$373816ac at atlanta.polycom.com>
	<198A730C2044DE4A96749D13E167AD37565E63 at MOU1WNEXMB04.vcorp.ad.vrsn.com><4697D229.7070207 at cs.utk.edu>
	<4697DC68.9060808 at gmx.net> <03f001c804e0$92860060$6a01a8c0 at DRTVnet1>
In-Reply-To: <03f001c804e0$92860060$6a01a8c0 at DRTVnet1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net
X-Spam-Level: 
X-Spam-Status: No, hits=-73.1 required=5.0 tests=AWL,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=2.63-arin1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: Stephen Sprunk <stephen at sprunk.org>, "ietf at ietf.org" <ietf at ietf.org>,
	Paul Hoffman <paul.hoffman at vpnc.org>
Subject: RE: IPv4 to IPv6 transition
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

The shortage of IPv4 addresses in developing countries in a red herring. Al=
l 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 runn=
ing 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 inhibits the
> >> development/deployment of useful new applications.
> >>
> >
> > As Phillip stated, I don't see the problem with future applications.
> > Compare this with the security aspects that are taken care of much
> more
> > than before when developing new applications NAT traversal is just
> another
> > thing to think about as a protocol designer.
> >
> > Ciao
> > Hannes
> >
> >> Keith
> >>
> >>
> >> _______________________________________________
> >> Ietf mailing list
> >> Ietf at ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >>
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf at ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


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




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.