Subject: A modest proposal for Harald

From: [email-masked] (Noel Chiappa)
Date: Fri, 5 Nov 2004 18:15:50 -0500 (EST)

> From: Harald Tveit Alvestrand
    > Date: Friday, November 05, 2004 1:20 AM

    > I'm stepping down as IETF chair in March, and I am not a candidate
    > for reappointment.

Harald:

I too would like to congratulate you on your successes, and suggest you have
the opportunity to be the last chair to preside over active work related to
version 6 of the IP protocol suite. With the passage of more than 10 years
since IPv6 was adopted as the offical replacement for IPv4, and with the
contined small amount of actual IPv6 deployment, there is really no further
justification for any IETF working group to be discussing IPv6 in current
work. With all due respect to those who have put in a lot of effort over the
years in the attempt to make IPv6 happen, even people working on IPv6 have to
acknowledge that the size of the publicaly available IPv6 internet continues
to be very small; this is a poor sign for the adoption of IPv6. It should be
clear to everyone that although products that rely on current standards
activities will continue appear in the market place, the market is simply not
interested in deploying IPv6. As such I would recommend your legacy include
an active review of all working group discussions next week for items related
to IPv6, followed by closure of all IPv6 related work items before your
departure in March.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Nov 2004 18:33:00 -0500

--On Friday, 05 November, 2004 18:15 -0500 Noel Chiappa
<[email-masked]> wrote:

> I too would like to congratulate you on your successes, and
> suggest you have the opportunity to be the last chair to
> preside over active work related to version 6 of the IP
> protocol suite. With the passage of more than 10 years since
> IPv6 was adopted as the offical replacement for IPv4, and with
>...

--On Friday, 05 November, 2004 12:38 -0800 Tony Hain
<[email-masked]> wrote:

> I would like to congratulate you on your successes, and
> suggest you have the opportunity to be the last chair to
> preside over active work related to version 4 of the IP
> protocol suite. With the publication of the tunneling drafts
> that v6ops has been sitting on, there is no further need to
> discuss 32 bit address objects. At the same time, there is
> really no further justification for any other IETF working
> group to be discussing 32 bit addresses in current work. With
>...

Oh, my!  The potential for a plenary food fight that has nothing
to do with administrative reorganizations.  How very encouraging
and refreshing.   ;-)

      john

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 06 Nov 2004 00:58:51 +0100

Hi Noel,

Will all the respect, this is ridiculous.

You are out of the market, I feel.

We are deploying in Europe, now 3 "small" networks of 4.500, 5.500 and 8.000
sites, with dual stack, and probably turning them into IPv6-only quite soon.
Customers ask for it, not actually me pushing anymore.

Is curious also that the one for 5.500 was only 4.700 sites a few weeks ago,
and now grow in just a couple of weeks to 5.500. They are happy to get a big
network with real end-to-end !

And I'm sure that there are a lot of similar cases behind the scenes. I know
about some others that can't disclose, but also know about a lot of big
industrial players, for consumer products, which already moved IPv6 from the
R&D labs to their production plans, with products in the market for the next
year.

All the big Telcos are already deploying (or have done already) IPv6 in
their backbones. Access networks are slower, but this is absolutely normal,
in my opinion, and partially because we, IETF, aren't doing a faster job.

Everything takes time, and specially Internet with IPv4 is not something
that is so easy to get "updated".

Regards,
Jordi

> De: [email-masked] (Noel Chiappa)
> Responder a: [email-masked]
> Fecha: Fri,  5 Nov 2004 18:15:50 -0500 (EST)
> Para: [email-masked]
> CC: [email-masked]
> Asunto: A modest proposal for Harald
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Nov 2004 23:05:08 -0500

> to do with administrative reorganizations.  How very encouraging

The quality of the ballistic grub might be higher than usual at any
rate, since the IPv6 camp has a known preference for fine single
whiskey and I can attest from personal experience that Noel mixes a
mean pina colada.

Hmm, flying pigs, high (proof) spirits, and a brawl -- sounds like an
appropriate pre-retirement party for a Viking chieftain at that.

:)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 06 Nov 2004 09:53:00 +0100

Noel and Tony,

thanks for offering such wonderful foils for a technical discussion!

I'm going to do my best to rile the feathers of both of you, by appearing 
to take a strong stand, but actually remaining solidly perched on the fence 
between your positions, and manage to rile some so-far unruffled feathers 
in the mix.

How's that for stimulating interesting discussion??????

One of the slides I use regularly says about what the IETF does:

- Maintain the IPv4 Internet
- Enable the IPv6 Internet
- Create the mobile Internet

Frankly, folks, IPv4 is what IBM used to call "functionally stabilized". 
And it's got NATs in it. NATs stink. But (sorry, Brian) - IMHO, they are 
going to stay in the IPv4 Internet forever. So a major part of 
"maintenance" is learning to live with the little monsters.
News for you, Tony - 52 months is more than 4 years, which is bigger than 
the effective lifetime of Gopher. Still plenty of time for another dot-com 
boom'n'bust cycle.... and as I see it, we're never going to run out; the 
market will just raise the price of IPv4 addresses until the market balks. 
Just like crude oil, but quite a few years sooner. Luckily, unlike oil, 
alternates exist!
So the death of IPv4 isn't going to happen with a bang. More like a 
protracted series of whimpers - from the accountants paying for those pesky 
numbers.

In IPv6, I see our job as standardizers to make sure the thing we have 
defined is well-defined enough to let it work, and then get the hell out of 
the way.
At this time, it's the users and the network builders who will decide 
whether we've succeeded or failed. Not us standardizers.
We can do minor maintenance and "hey, we didn't mean it that way", but the 
best we can do for IPv6 is to point out all the stuff that is done, stable, 
and is NOT going to change any time soon.
And despite the best efforts of the people overselling benefits of IPv6 
that actually aren't v6-specific, and the people clamoring for "just 
another fundamental tweak to the architecture", I think this is succeeding.

But on mobility, I think we blew it.
Our first attempt - Mobile IPv4 (or Tethered IPv4 as I called it after I 
understood what a Home Agent really is) is a failure, in no small part 
because its design ignored firewalls and NATs (the nasty little buggers).
So app-level switched to the "mobility by DHCP" instead - get a new IP 
address and let the applications do the reconnect dance, each according to 
its own nature. Baroque enough to make grown GSM engineers weep.....
It's possible we're going far enough back on a reset that Mobile IPv6 
(which I do NOT understand) does better, and that the "mobile networks" 
thing is finally understanding the reality that a device is no longer a 
single thing - clusters of them move together.
But we've still got lots of fun and games here for years to come.

Food enough for thought?

                      Harald

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 06 Nov 2004 14:57:32 +0100

Dear Harald,
This the first time I agree with everything in an IETF mail. Thank you to 
be candid enough to have writen this.

May I just suggest one tunning: "Investigate" rather than "Create the 
mobile Internet"? To preserve the possibility that there is not such a 
thing as a "mobile", or a "multilingual", or a "local",  or a "secure", or 
an "objects" etc. Internet (or by the way an IPv4 and an IPv6 Internet). 
But a more elegant way to conceive an Internet's single architecture, to 
permit every host and agent to be (virtually) mobile, multilingual, local, 
secure ... as every of the related features and services might be used, one 
way or another, by every interconnecting box.

Thank you.
jfc

On 09:53 06/11/2004, Harald Tveit Alvestrand said:

>to take a strong stand, but actually remaining solidly perched on the 
>fence between your positions, and manage to rile some so-far unruffled 
>feathers in the mix.
>
>protracted series of whimpers - from the accountants paying for those 
>pesky numbers.
>
>defined is well-defined enough to let it work, and then get the hell out 
>of the way.
>best we can do for IPv6 is to point out all the stuff that is done, 
>stable, and is NOT going to change any time soon.

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Nov 2004 12:36:08 -0500

Harald, 

While I agree with most of your analysis, I think there is a
different view of address space exhaustion that might be more
helpful and that there are several things the IETF can do to
impede the spread of IPv6.  The other side of the "why bother
deploying it" argument is "ok, we've decided we need to deploy
it sooner or later because <pick your reason>, what are the
impediments to doing it now versus incentives to delay".

You wrote...

--On Saturday, 06 November, 2004 09:53 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

>...
> .... and as I see
> it, we're never going to run out; the market will just raise
> the price of IPv4 addresses until the market balks. Just like
> crude oil, but quite a few years sooner. Luckily, unlike oil,
> alternates exist!
> So the death of IPv4 isn't going to happen with a bang. More
> like a protracted series of whimpers - from the accountants
> paying for those pesky numbers.

Yes, although there will also be bangs.  For example, prying
legacy Class As (/8s) out of the hands of some of the holders
who don't have them utilized optimally (whatever that means at
the time) is likely to require either levels of money that are
well above the pay grade of accountants or drama in
international relations.  But I believe that a better measure of
"when do we run out" is when technically or administratively
bizarre things start happening because of the perception that
addresses are too scarce or expensive or hard to obtain.  Every
time someone is told "the third or fourth public address for
your SOHO network is going to involve an astronomical charge",
it should be taken as a sign that we are already out of IPv4
space.  Every time someone wants to multihome, or even create a
dial backup for, a small network and discovers that there are no
options that avoid NATs, it is a signal that we have run out of
IPv4 address space.  Every time a vendor ships a relatively high
end, "professional", small enterprise router or firewall that
forces the LAN to be NAT-only because they can't figure out how
to support public addresses on that LAN, it is a sign that we
have already run out of address space or worse.  And every time
a protocol design becomes vastly more complicated because of the
need to deal with private address spaces (especially cascaded
ones), it is a sign that we are already out of IPv4 space.

The point isn't how restrictive RIR policies might get as the
wolf is seem approaching the door, or how expensive the
next-to-last available block might be, but when the design of
the network and its protocols and applications start being
distorted by the perceived space shortage.  I suggest we crossed
that line some time ago.

However,

> In IPv6, I see our job as standardizers to make sure the thing
> we have defined is well-defined enough to let it work, and
> then get the hell out of the way.
> At this time, it's the users and the network builders who will
> decide whether we've succeeded or failed. Not us standardizers.
> We can do minor maintenance and "hey, we didn't mean it that
> way", but the best we can do for IPv6 is to point out all the
> stuff that is done, stable, and is NOT going to change any
> time soon.

Even if we ignore the address space issues entirely, we will
slide smoothly from "NATs in IPv4" to "NATs in IPv6" or, more
likely, "ever more clever NATs and NAT technologies in IPv4"
unless we are successful in nailing down the mechanisms to
accomplish the sorts of configuration and goals in IPv6 that are
causing NATs in IPv4.  My sense is that we haven't done that
yet.  We may even be a bit behind where we thought we were 18
months ago.

Conversely, I keep running into organizations who look at IETF
activities relative to IPv6 and say things like "if they are
still developing/ designing IPv6 in the standards bodies, it
isn't ready to deploy yet; maybe part of the Internet's success
is that they haven't felt a need to mess with IPv4 in a very
long time".  I think the IETF hasn't been nearly sensitive
enough to that issue, which falls in the "shoot selfs in foot"
range.

    john

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Nov 2004 19:49:39 +0100

> yet.  We may even be a bit behind where we thought we were 18

The real sad thing is that many people operating enterprise or
even university networks get so used to NATs that they can't 
imagine to live without them anymore. They feel kind of naked
without a NAT and they will likely insist on NATs when you get
them to deploy IPv6. Fixing a mis-guided public opinion is
close to impossible. (Still, IPv6 is worth all the efforts
for those who understand the pains and prefer lots of cheap
global addresses. ;-)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Jari Arkko <[email-masked]>
Date: Sat, 06 Nov 2004 21:09:02 +0200

> But on mobility, I think we blew it.

I don't know if I agree with this -- most users that I
know are pretty mobile and certainly wireless. So I think
we do have some kind of a "Mobile Internet" already and
there's obviously more to come.

I do not want to comment on the specific mobility protocols.
But I'd like to suggest that we tend to think of Mobile
Internet issues in a too narrow sense. IP layer mobility
is just one part of the complete picture. What we really
need is an Internet that works transparently, seamlessly,
and securely in a world where connectivity is over wireless
and changing all the time. And yes, more work will be needed.

Here are some of the necessary components:

o  Is our infrastructure ready to provide network access
    to a large number of users, roaming across different
    types of providers? Some of you may not be aware that
    IETF provides much of the infrastructure components that
    link layers use to grant access, such as AAA. And yes,
    ubiquitous network access requires that providers get paid
    for their service.

o  What are the protocols that are used at the client end
    for authentication and authorization? Are we stuck with
    web-based logins? Or is 802.1X the answer, or cellular
    network models?

o  Does everything work when you combine them together?
    Does it work with NATs, v4-v6 transition and
    the simultaneous use of VPNs or multiple interfaces?
    Do the protocols expect you to transition to IPv6
    completely before you can begin deployment of the
    additional features? Seems like there's a lot of work
    to be done in this space...

o  Do our layer 3 "control" components such as RD, ND,
    and DHCP provide sufficient capabilities for, say,
    detecting when an L3 change has occurred?

o  Movement performance. There are many factors in
    this -- I recently counted how many messages one
    needs to attach to a commercial 802.11 network using
    IPv6. The result was 24 messages, but I may have
    missed some. Ongoing work in various IETF and IEEE
    groups is making this faster, but work remains.

o  Transport implications. How do transport layers and
    applications react to underlying communications path
    changes? If a mobility or multihoming protocol hides
    topological movements from upper layers, does it still
    need to tell TCP to do another slow start?

o  Are all of our protocols capable of operating
    in heterogeneous network conditions?

Many of the above things (though maybe not all) are
being addressed by different IETF groups. Just wanted
to point out that the issue is larger than Mobile IP.

--Jari

---

From: shogunx <[email-masked]>
Date: Sat, 6 Nov 2004 09:27:39 -0500 (EST)

> for those who understand the pains and prefer lots of cheap

I am in total agreement there.  Redundant routes to the 6bone from my lan
are are beautiful thing.

Scott

> /js

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Nov 2004 23:14:36 +0100

Juergen Schoenwaelder wrote:
> close to impossible. 

Some of us are trying:
draft-vandevelde-v6ops-nap-00.txt

    Brian

(Still, IPv6 is worth all the efforts

---

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Nov 2004 13:53:33 -0500

On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote:
>  So the death of IPv4 isn't going to happen with a bang. More like
>  a protracted series of whimpers

One of the great dangers of having a history of success is the way it
blinds us to new ways to fail.

In the case of IP addressing evolution, the blindness is that our 
community presumes that transition to IPv6 is inevitable.  Hence, we 
have done a very poor job of providing compelling benefits for users 
and admins.  We have a grand promise -- and frankly it often sounds a
lot more like religious fervor -- about eventual benefits, but no 
claim of immediate benefit that grabs operations folks by their gut, 
driving them to adopt this change.

By way of noting one possible scanario that builds on today's reality
and leads down a path that never adopts IPv6, I'll ask:  

	What if users turned all leaf networks into private address space, so 
that public IPv4 numbers were needed only at the level of roughly 1 
per public interface?

This is, of course, the ultimate breakage of the end-to-end addressing 
model, but we tend to forget that the model is something rather 
esoteric to non-protocol geeks.  

We already must modify the architecture to deal with a much richer 
range of border policies than just differential routing.  Having it 
include partitioned address space is a pretty obvious step, given how
often we already are faced with that reality.

At the least, it means we had better have an end-to-end reference 
(identification) construct that is a) separate from IP Address, and b) 
works fine over IPv4.  To this end, work like Opes and the 
architectural aspects of multi6 might be rather more strategic than we 
have been acknowledging.

The problem is that we failed to evolve IP in a timely manner and in a 
way that was really convenient for real administrators.  Instead we 
took the approach that this needed to be done as a major system shift
and that "we would only get one shot at this change", so we also 
loaded quite a bit of baggage into the package.  And now we try to 
characterize the minimal deployment of IPv6 as if it represented 
success.  

Or perhaps the real problem was that what has been happening with 
NATs, et al, is fine but we that have preferred to tout our idealized
solution and ignored market pragmatics.

Please forgive me for noting that this kind of error is classic among
organizations that have had major successes and, therefore, believe 
that their internal intelligence is greater than that of the markets.  
A small variation on this error is when it is from the aggregation of 
successful companies.  The obvious example is OSI.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com

---

From: "Randy.Dunlap" <[email-masked]>
Date: Sat, 06 Nov 2004 16:41:51 -0800

> driving them to adopt this change.

[snip]

> successful companies.  The obvious example is OSI.

This happens over and over again with people who work on some
specific technology, like infiniband (just for one example).
People who are close to it think it's great, while others who
are outside of it think that they drank too much kool-aid.
Seems to be related to tunnel vision AFAICT.

-- 
~Randy

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 7 Nov 2004 12:36:53 -0800

Dave Crocker wrote:
> community presumes that transition to IPv6 is inevitable. 

A transition away from IPv4 is inevitable. The next stop in the evolutionary
path will be determined by available alternatives. The IETF chose IPv6 from
the set of proposals on hand. The market will choose something else if the
IETF doesn't get serious about focusing all effort in that direction. 

> Hence, we
> and admins.  

Which is why I have been after the Applications Area to wake up and
recognize that the wasted effort that goes into the random nat traversal
schemes is not leaving time to do the necessary work focused on IPv6.

> We have a grand promise -- and frankly it often sounds a

Addressing is plumbing and nobody cares besides the network operator.
Applications are the driver that pull technologies along for the ride. Until
the apps community decides that continuing to put energy into a dead end
technology is a bad idea, we will be stuck on the current path with no
compelling driver for change.

> that public IPv4 numbers were needed only at the level of roughly 1

This is happening due to lack of choice. Network operators are finding that
their support costs are going up due to app breakage and that it is
impossible to offer service guarantees when someone else owns the nat
component of the infrastructure. 

> esoteric to non-protocol geeks.

You say this as if the model were the goal. The goal is simplicity that is a
direct output of the model. 

> often we already are faced with that reality.

Talk about blindness. Has ten years of nat deployment lead to the perception
that it is just a minor annoyance that has to be dealt with? Yes we have to
deal with rich border policies, but that is not really a new requirement.
The U.S. National Labs were implementing whatever the technology of the day
allowed 15 years ago, but their policies at the time were not much different
than the Dentist office today. Differing policies was the root of most of
the inter-agency discussions about topology before the commercialization
phase. 

> architectural aspects of multi6 might be rather more strategic than we

Opes has potential for both mitigating some of the harder problems, and/or
being a way to trivially subvert system integrity. Lacking a real global
trust infrastructure people have piled the trust issue on the routing system
through the address token. The simple act of creating alternative endpoint
tokens does not automatically move all the trust assumptions. What basis
will people have to trust Opes. 

Multi6 is a worthwhile strategic effort, but the proposals on the table
represent an even greater change to the fundamental architecture than simply
changing the address length of IPv6. As such it will not really be
deployable before 2020, and that is if the array of research efforts can be
focused down to a single proposal soon.

> way that was really convenient for real administrators. 

Some of us knew and discussed going in that it would be a 10 year effort to
make a change of this magnitude. Bickering over attempts to tell the
operations community how to run their networks has slowed things down, but
deployments are happening around the world and given product availability
could easily accelerate with the arrival of compelling applications. 

> Instead we

One of the biggest problems is using the current measures of IPv4 deployment
to gauge IPv6 success. This is more indicative of the IETF's blindness than
anything else. Given the current allocation policies the routing system will
never see the massive bloat we see today (those policies are likely to
change over time though). 'Demand' for blue-plumbing instead of red-plumbing
should never happen because the end user of the network should never see it
or care. The measure we should be looking toward is application availability
and use. To a large degree the app development community is being misled by
the IETF's continued efforts at squeezing the last address out of a system
we have long since outgrown.

> solution and ignored market pragmatics.

Market pragmatics of the last few years said the world couldn't wait for the
IETF to get its act together and expand the available space. Market
pragmatics going forward are more likely to say that nats create an
unnecessary expense, both in the cost of the development armies working on
traversal hacks and as the source of operational confusion leading to more
support calls. Granted I am called in to talk to people already interested
in/asking about IPv6, but those are the two points that keep coming up in
the market place today.

> successful companies.  The obvious example is OSI.

Yes the IETF as a whole is blinded by the success of IPv4. Yes there are
participants that want to tell the world how to run their networks. At the
same time, there are others who are interested in simply defining the growth
path and as Harald said, '... make sure the thing we have defined is
well-defined enough to let it work, and then get the hell out of the way.' 

The plumbing pieces are well defined. The deployment technologies are
defined, though several are blocked from publication by those who don't want
to 'get out of the way'. The 'internal intelligence' of the collective
recent IESG membership has created a road block for deployment technologies
that don't fit their model of how people should be running networks. The
real pieces that are lacking in the IETF output are in the application
space. As Brian noted, work is going on now to address the market
perceptions about what nat does and how to accomplish the same tasks in IPv6
without nat. This is nowhere near enough to help the world of application
developers understand how to create-in and/or port-to an IPv6 environment.

As Harald also said, 'Frankly, folks, IPv4 is what IBM used to call
"functionally stabilized".'  This means there is no reason for the IETF to
focus any effort on standardizing new functionality around it. This was the
basis for my comment about closing down IPv4 related discussions during his
term. Yes there will be new IPv4 based product and service developments in
the market for years to come. That is both due to training of the existing
developers and operators as well as the fundamental need to leverage the
vast existing environment. Those product and service developers do not need
any new output from the IETF to create their wares. At the same time they
will need output from somewhere to move beyond the limitations of that
existing environment. The IETF has a choice, it can either make its earlier
IPv6 choice the default for all current work, or it can become irrelevant
when someone else provides a replacement for the 'past its prime' workhorse
of IPv4. This is simple market pragmatics, no religion required. 

Tony

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Nov 2004 11:22:34 -0500

On 11/6/2004 3:53 AM, Harald Tveit Alvestrand wrote:

> defined is well-defined enough to let it work, and then get the hell
> out of the way.

Pardon me for saying so, but I think that represents the canonical problem
with v6 deployment and some other large-scale efforts; there hasn't been
enough solid leadership promoting the agenda. By way of analogy, the I*
collection of bodies is really good at things like facilitating discussion
about the kinds of laws that we all want to live under, but they are lousy
at doing things like building the interstate highway that actually lifts
the system upwards.

Usually this is good, because usually there are vendors out there that
will do the build-up work, and we can let the market take its own path.
But in the case of IPv6, there is a real dearth of products to choose from
(especially in the SOHO space), and there is a real lack of availability
from ISPs. It's not just impractical for SOHO networks to deploy IPv6, it
is almost foolish to even try given the lack of availability. The right
fix here is to make IPv6 deployment easier. I think the RIRs are falling
down here -- everytime a request for a /24 IPv4 block is rejected, the
letter should be accompanied with an offer for a /24 IPv6 block, for
example. Similarly, vendors need to be met with and encouraged to "take
one for the team" so to speak, and sink R&D money into products. Both of
those are areas where the I* has not done well, and where comments like
Harald's above make success less likely. Like I said, such a position is
usually okay, but in this case it's not the appropriate tact.

We're going to see another multicast here if we don't do this kind of
work. Then we'll see another "spam problem", where the shortcomings
eventually do bite us in the collective butt because we've shown no
leadership until it was too late.

There is still some technical work that needs done, too. NATs exist
because (1) address space is difficult to get but also because of routing
table limitations. If BGP can't handle millions of IPv4 /24 blocks, why
will millions of IPv6 blocks work better? What do you mean it won't?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Thomas Narten <[email-masked]>
Date: Wed, 10 Nov 2004 20:18:09 -0500

> But on mobility, I think we blew it.

Not sure if you are referring to the mobile IP technology in
particular, but because I suspect that the following is a bit of a
secret to the larger community, mobile IPv4 is actually deployed and
used. And end users mostly don't even know it!

Excluding cdma 2000, I'm told that it is deployed in O(100K)
nodes. This is in roaming notebooks and handhelds. Looking forward,
this number could get substantially larger, should appropriate ROHC
profiles be developed, though that work has not been started AFAIK.

Looking at cdma 2000 (aka 3GPP2), it is deployed in cellphones in both
Sprint PCS and Nextel. In such phones, when IP service is enabled,
mobile IP is used.  I'm told that MIP is deployed in O(million)
devices here (i.e, there is O(10M) subscribers, though it is unclear
how many are also subscribed to IP service).

There are some other deployments, but I don't know how big.

Thomas