Re: FW: Why?

I have a totally different evaluation of the IPv6 issue I suggest you to 
consider.
IPv6 was specified as "IPv4 with larger addresses", this is what has been 
delivered and this is what is deployed by the RIRs and demanded by the 
market. One uses IPv6 as an extended IPv4 space. Any pressure for IPv6 will 
give the feeling that IPv6 is not IPv4 fully compatible and will lead to a 
disinterest of IPv6 (because IPv6 is the least used one, please will strive 
for stability). To say that IPv6 is better is even worse and will push 
people to better IPv4 (with NATs and others). To look for "the killer 
application" is the worst signal to the market: the market does not want 
revolution but services. (NATs are a general patch concept: HTTP.1.1 is 
another way to save on IP addresses which is more blocking the Internet 
development than NATs. NAT are now userboxes which are used for many other 
purposes and will stay).
The reason we need IPv6, IMHO is totally different. We need its size and 
flexibility to switch the internet from being an access network to an 
interactive network. I explain: when you start building a network you build 
its addressing to optimize the routing with the resources you have 
(centralized then  decentralized network -the network of networks is 
decentralized). Then your network grows, and there is a time it can become 
a distributed network (the initial Paul Bahan/Louis Pouzin catenet concepts 
now permitted). The leader is no more the routing but the directory. So, 
you do not adapt the addressing to the routing (as do the RIRs) ,you design 
the routing to match the addressing. IPv4 or IPv6 is allocated along the 
same line by the RIR. This was the initial phase of the internet. In the 
case of the Internet its mature phase needs addressing schemes most 
probably more based upon geopolitic structures of the demand (but it would 
be fool to dedicate the addressing to such an approach only).
The IETF had five things to do.
1. to identify the need. It did it with "longer address". It did not 
identify the legacy/global transition aspect (NGN?) but that was really up 
to the ICANN process to do it.
2. to develop the standard. Done.
3. to guide the experimental phase what it did with the legacy deployment 
(RIRs). Done.
4. to transfer to the market operators what has been made with NRO being 
now formed and now ITU. May be sometime Space and Geography blocks. Done.
5. to support their specific needs to permit them to be complementary and 
adequate to their markets, their coopetition supporting their deployment 
and fostering cost reduction, stability and innovation. This is the phase 
we are entering now.
The first need they all have is that IPv4 becomes fully IPv6 compatible. 
When this is achieved, the transition is achieved.
For what it may be worth, from the users side.
jfc

At 13:04 11/03/2005, Joel M. Halpern wrote:
> 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