Re:Why?

I think it should be in the other way around. Show the developers and
service providers that some applications can take advantage of IPv6 and
require less effort to be developed (because no need to care of the NAT),
and consequently less cost, less investment.

IPv6 is an innovation opportunity, and makes life more simple to everyone,
and consequently can generate more business.

The ISPs need to look IPv6 as a way to aggregate services and applications
and get a couple of extra euros for every service, every month, form every
customer. This can make a huge difference, specially when the revenues for
the access price are going down and down (and the bandwidth high and high),
and consequently they will not even able to cover the access cost with that
fees.

Starting to charge for IPv6 addresses, using IPv6 NAT, and so on, will not
help, on the other way around, will bring us to the same situation as with
IPv4 in terms of innovation and development of services and applications:
BUSINESS.

In the long-term I don't think the Telcos/ISPs will take that path, because
is against their business, their opportunity to add value to their networks.
But they may have for some time the wrong perception about this, and is also
our mission to avoid that happening as much as possible, probably educating
them, as I feel this only happens precisely because the lack of knowledge or
strategic vision about the future of Internet.

What we can do about that ?

Regards,
Jordi

De: "Joel M. Halpern" <joel(_at_)stevecrocker(_dot_)com>
Responder a: <ietf-bounces(_at_)ietf(_dot_)org>
Fecha: Fri, 11 Mar 2005 07:04:52 -0500
Para: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Asunto: Re: FW: Why?

This discussion seems to take as a premise the view that if we define
applications only on IPv6, even though they could be defined on IPv4, that
this will give people a reason to use IPv6.
It also seems to take as a premise that if we don't define ways to work
around NATs, people won't use the applications with NATs.

The fact is that external evidence indicates that both premises are false.
For a long time we tried ignoring NATs.  As a result, people crafted many
strange and non-interoperable ways to work with NATs.
I know of several initiatives that tried to define their protocols for
IPv6.  Some even thought they had good reasons.  Before the work was even
done, I saw customers requesting vendors to supporting the initiative using
IPv4 directly.

Trying to pretend something won't work with IPv6 is not a substantive value
add for IPv6.

Not needing NAT is a minor value add for IPv6.  But we have already seen
several major corporations publicly indicate that they intend to use NAT
with IPv6, even though they can get enough public address space.

As far as I can tell, following through on the kind of approach discussed
here would simply make our products les useful, and reduce actual
interoperability in the field.

Yours,
Joel M. Halpern

At 05:36 AM 3/11/2005, shogunx wrote:

On Thu, 10 Mar 2005, Erik Nordmark wrote:

Tony Hain wrote:

Why are we wasting effort in every WG and research area on NAT traversal
crap???


FWIW I'm also concerned that we are doing too many different NAT
traversal protocols. It should be sufficient to just define how IPv6 is
tunneled across NATs and start using more IPv6 in the applications.


I agree wholeheartedly.  Lets face the reality of the situation.
Carriers have abused IPv4 for financial reasons.  As a result, NAT is
widely deployed, because it was and is an effective workaround for
dealing with siad carriers trying to squeeze extra money from IP
addresses.  There is nothing that can be done about that now, except
implement the solution that has been written to solve the problem, IPv6,
right on top of the existing NAT's.  With full application layer support
for v6, NAT will eventually deprecate, and be little more than a bad
memory.  The open source community has a wide variety of v6 enabled
daemons and clients already, for almost every widely used protocol.  While
these can easily be implemented on any host, good luck getting the general
public to do so.  The solution for migration most likely lies in somebody
developing a little v6 router, that autoconfigs a tunnel with a small
allocation of addresses.

Scott

On another topic, why is it that the API is so sacred that we will create
a massive array of complex approaches to avoid defining a real session
layer. We put imitation session efforts at layer 4 (SCTP), layer 3.5

(HIP),

layer 3.25 (shim), and the TRILL crap is trying to do it at layer 2.5.


I don't understand what makes you think TRILL is trying to do a session
layer. If it does, then any other routing and tunneling approach should
also be given the same verdict.

    Erik

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf