Subject: Is IPv6 died ?

From: Mounir Eddabbabi <[email-masked]>
Date: Thu, 10 Feb 2000 19:23:52 +0100

Hi every one

I have just assisted in a conference of a technical leader in a company
of telecommunication (field of
investments: ATM) that IPv6 died !!! What must I answer it especially
that it has just said to me that all
the problems relating to addressing, the routing and the quality of
service are solved once for all. I would like to
know your contribution so that I can answer it in a collective way.

Best regards

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2000 17:18:04 -0600

Mounir,

You have been seriously misled. Those problems have certainly not been
solved and IPv6 is far from dead. 

There is a short-sighted mentality that prefers to deny the intrinsic
problems of the 32-bit address space, and it has some vocal advocates.

That doesn't mean that deployment of IPv6 is an easy thing - it will still
take us most of the next ten years.

You can find some of the issues explored in 
http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt
which will be published as an RFC within a few days.

Regards

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

> know your contribution so that I can answer it in a collective way.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 Feb 2000 09:37:32 -0500

Mournir,

You have gotten a lot of good responses and so I will not repeat.
In 2000 we will see IPv6 products deployed that offer an alternative to
NAT with IPv4.

In a book I will be getting into the market very soon I will depict the
horrors very clearly of the existing debaucle breaking the end-to-end
model much further than the IAB transparency draft and in much greater
technical detail.  Thats whats happening now the end-to-end model is
being assaulted and IPv6 will be the counter-attack.  Go take a look at
the NAT WGs list of things NAT breaks its unbelieveable and RSIP is not
going to fix all that either it is just another bandaid.  The patient is
turning green and until the elixir of IPv6 is provided the patient will 
continue to have ill-health.

If you can find the time come to the IPv6 U.S. Summit in Telluride
Colorado March 13-17 sponsored by the IPv6 Forum.  This is where you can
learn why IPv6 is not dead, meet customers that will deploy IPv6, and
meet the vendors who can speak freely without being IETF politically
correct  (as on this list) who are investing millions of dollars in the
development of IPv6 for desk tops, servers, routers, and other products.

And come see my talk "How To Get to IPv6" and NOW, and other talks from
product engineers and product marketing people who will clearly
articulate the technical, business, and future product reasons IPv6 will
happen and will not die.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 Feb 2000 12:05:33 -0500

Brian,

Your wondering why this kind of press happens well lets look at some of
the words in your conclusions of the 
http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt

------------------------------------------
   The notion that servers can use precious globally unique addresses
   from a small pool, because there will always be fewer servers than
   clients, may become anachronistic when most electrical devices become
  network-manageable and thus become servers for a management protocol.
  Similarly, if every PC becomes a telephone (or the converse), capable
  of receiving unsolicited incoming calls, the lack of stable IP
   addresses for PCs will be an issue. Another impending paradigm shift
  is when domestic and small-office subscribers move from dial-up to
   always-on Internet connectivity, at which point transient address
   assignment from a pool becomes much less appropriate.
-------------------------------------------

But it will work for early IPv6 adoption as interoperation tool for IPv4 and
IPv6.  Please define how your using "anachronistic" here.. I am not
clear how your using it in the network context.

-------------------------------------------------
5.2 Complete failure of IPv6

   In this scenario, IPv6 fails to reach any significant level of
   operational deployment, IPv4 addressing is the only available
   mechanism, and address transparency cannot be restored. IPSEC cannot
  be deployed globally in its current form. In the very long term, the
   pool of globally unique IPv4 addresses will be nearly totally
   allocated, and new addresses will generally not be available for any
  purpose.

   It is unclear exactly what is likely to happen if the Internet
   continues to rely exclusively on IPv4, because in that eventuality a
  variety of schemes are likely to promulgated, with a view toward
   providing an acceptable evolutionary path for the network. However,
   we can examine two of the more simplistic sub-scenarios which are
   possible, while realising that the future would be unlikely to match
  either one exactly:
-------------------------------------------

To even suggest this from the IAB is counter-productive and I think the
IAB should give justification why this is even possible given the
present momentum of IPv6 and the current rate of deployment by vendors
and discussion in the Wireless and Mobile areneas.

If IPv6 did not happen the IETF has failed to pick the right IPng when
we chose SIP and then developed IPv6.  The IETF will be fired by the
world networking comunnity, the market, and vendors.  We will go fix it
out of the IETF in a new standars body is my prediction.

The IETF exists because the market lets it exist it is not an entity
unto itself with no higher authority.  The higher authority is the
market and the market is not happey with the band-aids on IPv4.

------------------
   Suppose that a mechanism is created to continuously recover and re-
   allocate IPv4 addresses. A single global address space is maintained,
  with all sites progressively moving to an Intranet private address
   model, with global addresses being assigned temporarily from a pool
   of several billion.
--------------------

This is not going to ever happen anymore than it is now.  This is where
the ITU, ETSI, and ICANN will join together with help from people like
me to suggest an alternative most likely IPv6 and an end to the IETF.

-----------------------------
   5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT
  (NAT with port number translation). This has the disadvantage that
   the host is unaware of the unique address being used for its traffic,
  being aware only of its ambiguous private address, with all the
   problems that this generates. See [NAT-ARCH].
----------------------------

Add see the applications that will not work with this in NAT-ARCH.
But many users are stuck with this for now and not happy.

-------------------
   5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP
   addressing implemented at the host rather than by a NAT box. See
   [RSIP]. In this case the host is aware of its unique address,
   allowing for substantial restoration of the end-to-end usefulness of
  addresses, e.g. for TCP or cryptographic checksums.
---------------------

Good band-aid if we must have them but requires running code on all
clients for it to work.  An alternative and like this will be used via
DSTM for IPv6 early adoption.

--------------------------------
   5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model
   in which address translation is replaced by systematic encapsulation
  of all packets for wide-area transport.  This model has never been
   fully developed, although it is completely compatible with end-to-end
  addressing.
--------------------------------

How about a technical reference to this or delete it from the draft.
It does nothing more than detirorate to NAT in the a tunnel.

--------------------------------------
6. Conclusion

   None of the above scenarios is clean, simple and straightforward.
   Although the pure IPv6 scenario is the cleanest and simplest, it is
   not straightforward to reach it. The various scenarios without use of
  IPv6 are all messy and ultimately seem to lead to dead ends of one
   kind or another. Partial deployment of IPv6, which is a required step
  on the road to full deployment, is also messy but avoids the dead
   ends.
--------------------------------------------

Excuse me IPv6 is clean and straight forward and the only part that is
not simple is transition.  Why is partial IPv6 deployment messy?  The
only thing that is messy is sitting around in the IETF for 5 years
trying how to do transition.  It is time the vendors just go do it and I
am not clear the IETF should have ever been involved with the transition
aspects of IPv6 other than as a forum to discuss and work out technical
scenarios.

/jim

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 11 Feb 2000 09:48:05 -0800

Brian,

> solved and IPv6 is far from dead. 

However, it would be equally misleading to believe that IPv6 solves
the routing and QoS any better than IPv4 - it does not. 

There is a short-sighted mentality that prefers to deny the intrinsic
relationship between addressing and routing, and claims that in order to
scale the Internet, all one needs to do is to make IP addresses
larger. With this in mind it would be somewhat naive (to say the least) 
to claim that IPv6 significantly improves the ability of the Internet
to scale.

Moreover, the falling sky of IPv4 depletion is further off than many
proponents of IPv6 would have one believe. Let's not confuse facts with 
opinions. Wrt some facts the following is from
http://moat.nlanr.net/IPaddrocc/18monthSequel/:

   The address occupancy for the two dates were: 
   
        27 November 1997: 
             3,538,970 Class-C equivalent host clusters 
             maximally supporting 905,976,320 hosts 
             utilizing 21.1 percent of the totally available addressing space 
        27 May 1999: 
             3,752,222 Class-C equivalent host clusters 
             maximally supporting 960,568,832 hosts 
             utilizing 22.4 percent of the totally available addressing space 
   
   In other words, the actively used address space increased by roughly 
   6 percent over the 18 month period, while still staying below a quarter 
   of the available 32 bit address space. 

Finally, one needs to remember that IPv6 is just one possible solution
to the IPv4 address depletion problem, but not the only one possible.
While the alternatives (e.g., NAT) are not without problems, neither is
IPv6. Important to remember that each has its own set of tradeoffs,
these tradeoffs require careful cost/benefit analysis, and this
analysis may yield different conclusions depending on a specific
situation. 

Yakov.

P.S. While the ipng mailing may not be the place to discuss
alternatives to IPv6, perhaps there should be a mailing list
where such alternatives could be discussed...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 Feb 2000 13:02:11 -0500

There is no alternative to IPv6 and it is the IETF choice to solve
these problems long term with that mechanism and why it was chosen as
the IPng in the IETF not NAT, TUBA, and the alternatives.  We have
already had that discussion and all others have lost and IPv6 is the
answer.  And every vendor I know is implementing IPv6 right now for
production release.  Also at the IPv6 Forum our Key Note speaker is Judy
Estrin CTO from Cisco.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 Feb 2000 13:09:36 -0500

WEB Attacker states "deploy IPv6 as soon as possible"
see attached mail we just got on the IPv6 Forum.

/jim

From: Petri Bernhard <[email-masked]>
To: "'IPv6 Forum Members'" <[email-masked]>
Subject: ZDNET Article on the recent Web Denial-of-Service Attacks
Date: Fri, 11 Feb 2000 18:42:49 +0100
Sender: [email-masked]

There is a article in ZDNET quoting a hacker called "Mixter", who created
the tool allegedly been used in the recent Web Denial-of-Service Attacks,
at:
http://www.zdnet.com/zdnn/stories/news/0,4586,2436358,00.html

For IPv6, the interesting thing is that "Mixter" says that IPv4 can't really
prevent such attacks since "the real problem is the lack of authentification
in current protocols", so that the only possible way to prevent such attacks
is "migrating to IPv6 (the next-generation Internet protocol), which
provides necessary authentication facilities and a bunch of other security
extensions."

"Mixter" also says:
"IPv6 should get implemented as soon as possible, not only because of
security aspects, but because the growth of the Internet will make it
inevitably necessary by 2004, or sooner. The old IP protocol is a relic,
comparable to the Y2K bug. It is soon going to cause problems if people
don't care about it."

---------------------------

Kind regards
Bernhard

Bernhard Petri, Siemens 
Tel: +49 89 722-34578
Fax: +49 89 722-29098
[email-masked]
______________________________

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2000 13:23:05 -0600

Jim,

> http://www.ietf.org/internet-drafts/draft-carpenter-transparency-05.txt

I thought it was pretty clear: when most electrical devices (that means a
few hundred in every house and every car) need always-on IP addresses,
re-using addresses from a small pool will be an obsolete method. 
I wouldn't care to put a date on it.

It's not an IAB document. It was a submission by me to an IAB workshop.

> and discussion in the Wireless and Mobile areneas.

Personally I hope it isn't possible, but in scenario analysis you
have to consider multiple scenarios. There are plenty of people,
including at least one person who just wrote to this list,
who think the opposite to you.

...

Again, this is scenario analysis.

I agree.

There is no technical reference, as the second sentence indicates.
I don't think the comparison with NAT is correct, it is more
like inverted RSIP in fact.
> not simple is transition.  

I think that's what my words say.

> ...Why is partial IPv6 deployment messy?  

Because it leads us to v4/v6 translators.

I would like to add that each time I have given a talk based on this
document, people (plural) have come up to me afterwards and said "Now
I understand why we need IPv6." 

BTW you are too late with these comments; the document was approved for
Info RFC publication a while back and the RFC will be out any day.

   Brian

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 Feb 2000 14:36:12 -0500

Brian,

Intention was not to change the doc.  My comments are not needed for the
spec.  I accept your responses.  Glad to hear that people are telling
you they now understand.  That is good news and what I concluded too.

Do you disagree with me that IPv6 is the IPng selected by the IETF
processes to proceed standards track work on and that other ideas were
rejected after an open and extended process.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2000 13:34:10 -0600

> the routing and QoS any better than IPv4 - it does not.

I agree, to a close approximation. 

> to claim that IPv6 significantly improves the ability of the Internet

IPv6 addresses will aggregate better than IPv4 addresses, because we
have the luxury of enough bits to do aggregator-based address assignment.
This will limit the size of the default free routing table compared to
today. This is the only effect on scaling of the routing system.

However, the fact that IPv6 does not necessitate artificial separate addressing
realms does also indirectly help scaling, by reducing complexity and 
administration.

>    of the available 32 bit address space.

However, we know that if addresses were more freely available from the
registries, all the recent growth in private address space would have
been added to this. I agree that of course we don't know the end date
when 4 billion addresses will have been allocated; but it will come.

> analysis may yield different conclusions depending on a specific

Let's say that NAT and RSIP delay the evil day, but not for ever,
and they don't work in all market segments.

    Brian

---

From: Steve Deering <[email-masked]>
Date: Fri, 11 Feb 2000 12:19:18 -0800

>the routing and QoS any better than IPv4 - it does not. 

Neither Brian nor anyone else here said that.

>larger.

No one here claimed that.

> With this in mind it would be somewhat naive (to say the least) 

There are many dimensions in which the Internet has serious scaling problems,
some of which are solved by changing the IP header and others of which
have solutions that are largely orthogonal to the IP header format.  The
existence of the latter type of problem does not diminish or eliminate the
need to address the former type of problem.

>http://moat.nlanr.net/IPaddrocc/18monthSequel/:

Under a regime of rationing, consumption statistics tell you nothing
about the demand for the resource nor the degree of hardship suffered
by those denied the resource.

>alternatives to IPv6,...

It is definitely not the place.

>...perhaps there should be a mailing list where such alternatives could
>be discussed...

The big-internet list probably still exists, for those who wish to continue
such interminable discussions.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2000 14:21:16 -0600

Jim,

> rejected after an open and extended process.

Of course you are correct. 

   Brian

---

From: Jeff Williams <[email-masked]>
Date: Fri, 11 Feb 2000 14:52:51 -0800

Brian and all,

> I wouldn't care to put a date on it.

  Remember that "Always On" IP addresses pose a serious security
risk, which is well known and also well documented.  Although IPv6
addresses some of those "Security Holes" is is not yet ready for
"Prime Time", even though it has been in development for 7 or so
years.  Unless or until those "Security Holes" are adequately addressed
in an adequate manner as well as not infringing upon "Privacy Issues",
"Always-on" IP addressing is and will remain a potential serious
hazard.

> It's not an IAB document. It was a submission by me to an IAB workshop.

  Nice piece of spin here Brian.  One is practically the same as the other...  >;)

> Again, this is scenario analysis.

  Indeed it is a scenario analysis, all be it one that is unfolding before
our very eyes.  >;)

> Because it leads us to v4/v6 translators.

  With IPv8 this problem is avoided.

> I understand why we need IPv6."

  I have given talks about IPv8 with the same results.  >;)  In fact
many see IPv8 as viable but preferable to IPv6.  I find this strange
as it is really more of a partnership arrangement.

> Info RFC publication a while back and the RFC will be out any day.

  Well maybe it is time to start on revising this potential RFC?

>    Brian

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Feb 2000 00:52:06 +1100

Date:        Fri, 11 Feb 2000 12:19:18 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220800b4ca05bc514c@[171.71.38.63]>

  | The big-internet list probably still exists, for those who wish to continue
  | such interminable discussions.

It does, though it is currently disabled (for the past 3 or so years, the
only incoming traffic has been spam).   Should any traffic even wildly
plausibly suitable for that list appear on it, I will enable the list again.

kre

---

From: Jim Bound <[email-masked]>
Date: Sun, 13 Feb 2000 12:15:21 -0500

Hi Brian,

>Of course you are correct. 

Let me try to explain my anxiety here I am not picking on you or anyone
else.

OK.  I think if we in the IETF agree to the above (besides you and me)
then I have no issues with the IETF.  And I intend to work in various
mobile/celluar forums to influence that the IP work get done in the
IETF.  But if I thought in my darkest moments that those who do not agree
with the above and believe the IETF is still searching for an anwser to
IPng as I feel Yakov in his mail IMO alluded to, and such a supposition 
was supported by the IETF mgmt team, then I am bummed out about all the work, 
years, and time I have put into the IETF.  I work on many things I 
technically don't agree with and even change specs I am working on as a 
co-author to support consensus even when I feel the technical change a working 
group wants is technically wrong.  So I will always compromise (in 95% of 
the cases) to move towards consensus, and then if there is a business 
opportunity go build it as an engineer.  But if after 6 years of work if 
I thought this process in the IETF had any consensus that IPv6 is not the 
IPng I would feel betrayed as an engineer working in this standards forum 
and I think many others would too.  I am not talking about fixing IPv6 
parts that need to change that are not widely deployed, but a complete 
movement towards other than IPv6.  Then I would have no choice but go
work elsewhere on this stuff, etc... and all that would go with that
decision.  I do not think that is the case and Yakov's view that we may
need an alternative to IPv6 is a minority view and a non-standard view
in this IETF.  In fact I think anyother mail we get on this list
that there is an alternative is also bogus.

I think part of the lingering problem, in hindsight, from all this was 
the way we announced the IPng choice as an IPng Directorate on that sacred 
day at that sacred IETF meeting years ago (either Toronto or Seattle).  I
recall members of the press core I was sitting next to at the plenary
saying to me "Jim - well it sounds like all proposals won but SIP was
selected".  The consenus of our directorate I think was to announce this
in the nicest way possible, which Scott and Allison did.  But I did warn
that if we did it as nice as we did we would be dealing with the fact we
did not shoot the other proposals in the head publicly and directly in
the future.  History demonstrates in various scenes over the centuries 
that at times it is very wise to beat your opponent to their knees and 
then start recontruction, this may prevent future whining from ones 
opponents in the future, and permits them to move forward in a liberated
manner.

Lastly I don't understand why very bright folks who know routing very
well like Yakov don't put their engineer hats on and help make routing
work with IPv6.  I have put some time into NAT as far as reviewing
drafts for DNS and IPv4/IPv6 continuity and the affect to the APIs on a
NAT implementation.  I even work on it at my real job.  I started AATN
which spawned RSIP and support what Mike Borella and others are trying
to do here.  We have even adopted some of the wisdom as far as lessons
learned from NAT and address conservation (though the RIRs have an
extreme interpretations of that) for IPv6 Transition and early
adopter deployment scenarios.  It really comes down to being an IETF
team player I guess.

p.s. I intend to use your transparency draft as a reference in the book
I am working on so I am glad it will get RFC status.  Turns out it saves
me re-writing things.  The only thing I will do different is actually
show diagrams, figures, etc where many apps break or must be altered if
transparency is lost and then have a pain scale to users that
continually goes up exponentially, as things like translation is used
for IPv4 or for IPv6.  It really should be avoided whenever possible.

/jim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Feb 2000 11:35:58 -0500

Jim,

Couple of observations.

The IETF has rough consensus on the selection of IPv6. Rough does not
mean unanimous, nor does it mean that the detractors will necessarily
be silent. We all know that in the end, the market will determine what
happens here. The official IETF stance certainly has some influence
here, but it is limited and by no means definitive. Vendors tend to
act based on business cases.

Most, if not all of the detractors, seem to have fault with specifics
of IPv6 itself, but that doesn't mean they have an alternative that is
any more widely accepted.

> work with IPv6.

Folks that say routing doesn't work with IPv6 are of course being
dishonest. What some folks are saying is that routing in IPv6 (longest
match with provider-based aggregation) is fundamentally the same as in
IPv4/CIDR (and this is correct). Thus, the argument goes, why bother
with IPv6.  Of course, that is a strawman argument. We should keep in
mind:

- IPv6 wasn't designed to "fix the routing problem", despite what many
  folks wish. It actually fixes the "lack of globally unique
  addresses" problem. Plus, it has other benefits.

- Although IPv6 may not "fix" the routing problem, there is good
  reason to believe it will result in smaller tables than will result
  with continued use of IPv4 because of:
   - increased ease of end-site renumbering  (if more renumbering
     takes place, fewer instances of broken aggregation)
   - more aggressive aggregation from the start (no legacy assignments
     to deal with)
   - a multihoming model based on multiple per-host prefixes
     (prefixes for multihomed sites are not advertised as exceptions
     to achieve multihoming)

Finally, the IETF is always willing to look at new approaches to
existing problems. Whether a new approach merits serious work in the
IETF depends on the cost/benefit when weighed against the existing
solutions. So certainly, if a credible alternative to IPv6 was brought
up for consideration, the IETF would look at it. We would be foolish
not to. However, this is no different than with any other protocol in
the IETF.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Mon, 14 Feb 2000 12:39:25 -0500

Nice response Thomas...I don't disagree with anything you said.
I personally believe also IPv6 can be routed faster than IPv4 and the
lookups in the stack can use a better "fast-path".  Also because routers
are not to do fragmentation is a routing benefit too.

thanks
/jim

---

From: Norihiro Ishikawa <[email-masked]>
Date: Tue, 15 Feb 2000 14:51:43 +0900

Since I am not involved in any IP work, my position is fairly
neutral.

But, considering the ongoing discussion, the more realistic
approach is to extend IPv4 for fixing "lack of globally unique
addresses" problem. Considering the ultimate deployment of IPv4,
the solution should be compatible with IPv4 as much as possible.

Since I am not an IP expert, I am not sure whether this approach
is feasible or not.

I understand the technical merit of IPv6. But, to deploy IPv6,
the business and operational merit is more important.

To discuss this issue, it seems to me that a neutral forum in
IETF is needed, with the excellent guidance of IAB.

Any comments ?

Norihiro Ishikawa

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 Feb 2000 09:44:32 -0500

>Any comments ?

IPv6 deployment guidance will come from the IPv6 Forum where the
motivation is wide deployment of IPv6, development of partnerships 
with those who can help the deployment of IPv6, and to stimulate the
market so vendors will build and ship IPv6 products.  This is not the
function of the IAB or the IETF.

Some of us in the IETF deploy networking as a job in Intranets and the
Internet, but this is fiat and not a premise to base the function of the
IETF or IAB on for IPv6.

The IETF and IABs job is to build standards and prouide opinions on the
use of those standards.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2000 15:09:51 -0600

Norihiro,

That was the discussion we had in 1992 to 1994, which resulted in the
rough consensus to create and deploy IPv6. That was expected to take
about 15 years, starting 1995 and we are on track.