As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support
IPV6 (I could be wrong).
While they probably aren't the most popular routers, they are very
popular, and im sure plenty of cisco's smaller routers don't support it
either.
How ready is the 'net to transit to IPV6 in the future?
Should everyone be factoring in replacing big routers with IPV6 being
the only reason?
Just curious on others' opinions on this.
--Phil
As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support
IPV6 (I could be wrong).While they probably aren't the most popular routers, they are very
popular, and im sure plenty of cisco's smaller routers don't support it
either.
I am on the 6bone using a combination of 2600 and Zebras. The 2600 doesn't
do BGP6 yet, although it does RIP6 just fine. It's getting there...
How ready is the 'net to transit to IPV6 in the future?
Define "future". It's coming, although slowly. But then, why hurry? The
"emergency" was just another skyfall...
As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support
IPV6 (I could be wrong).While they probably aren't the most popular routers, they are very
popular, and im sure plenty of cisco's smaller routers don't support
it either.
I am on the 6bone using a combination of 2600 and Zebras. The 2600
doesn't do BGP6 yet, although it does RIP6 just fine. It's getting
there...
How ready is the 'net to transit to IPV6 in the future?
Define "future". It's coming, although slowly. But then, why hurry?
The "emergency" was just another skyfall...
Yes, I don't think we need it 'right now'. My concern is that at this
point many companies are still buying routers that as of today have no
support for IPv6. Given that a BigIron/65xx is mostly hardware
forwarding, I speculate that they wont be able to support IPv6 with a
trivial software upgrade (at least not at the same performance level).
So, is someone buying such equipment today 'wasting money' since it will
be completely obsolete with the onset of mass IPv6 roll-out likely in
2004 or 2005?
*If* 2004/2005 is a realistic expectation for a full rollout, then
*maybe*. The question becomes, is this realistic? I just don't think so.
Judging IP6's current status strictly in light of how far along the large to
mid sized providers are, I'd be surprised if a full scale rollout was closer
than five years out (which puts us at ~2007). Based on this, and Moore's
Law, the BigIron you bought today will be a BigScrapHeap by then anyway.
As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx
support IPV6 (I could be wrong).
It is rumored that Cisco has software for the 6500 that does IPv6,
albeit "in software" on the MSFC. And I'm sure they have plans to
support IPv6 in hardware on this platform at some point.
Foundry has something like "protocol-specific VLANs", which allows you
to bridge IPv6 traffic, while (Layer-3-) routing IPv4.
While they probably aren't the most popular routers, they are very
popular, and im sure plenty of cisco's smaller routers don't support
it either.
The smaller routers are generally not a problem as long as they have
enough memory to run recent IOS releases, and I think the bloat is
mainly due to new functions other than IPv6.
An interesting question is what it would take to support IPv6 on
appliance-like routers such as IP-over-Cable or -xDSL CPE. In the
retail space I actually see some interest in running IPv6, because it
makes it much more feasible to operate a small network at home, and I
have the impression that home users now lead enterprises in terms of
IPv6-enabled OS deployment (Windows XP and Linux in particular).
How ready is the 'net to transit to IPV6 in the future?
Let's say that most ISPs could satisfy the current demand 
Even though there are relatively few high-performance implementations
(read: ASIC-based IPv6 forwarding as Juniper has) out there, a modest
amount of IPv6 traffic could be carried "natively" on most networks.
If you need higher performance and don't have hardware forwarding for
IPv6, you can always tunnel in IPv4 (or, shudder, MPLS) at the edges.
You may also want to do this if you don't really need the IPv6
performance, but would like to protect the control plane of your
production (IPv4) service from the additional CPU load (IPv6 traffic
as a DOS on your RPs :-).
Should everyone be factoring in replacing big routers with IPV6
being the only reason?
Sure, provided everyone has infinite amounts of money, or the
additional revenue from IPv6 justifies the investment. Honestly I
don't think either is the case today for most of us, except where some
form of public funding exists, for example through innovation/research
subsidies or tax breaks for enterprises using IPv6.
* simon@limmat.switch.ch (Simon Leinen) [Tue 09 Jul 2002, 10:51 CEST]:
An interesting question is what it would take to support IPv6 on
appliance-like routers such as IP-over-Cable or -xDSL CPE. In the
retail space I actually see some interest in running IPv6, because it
makes it much more feasible to operate a small network at home, and I
have the impression that home users now lead enterprises in terms of
IPv6-enabled OS deployment (Windows XP and Linux in particular).
It would also be nice if operators with end users started offering
native multicast. Although the AMS-IX multicast initiative started
off with lots of enthusiasm, two years later it seems to have died
almost completely.
Back to the subject of IPv6: One operator here in The Netherlands (60K+
ADSL customers, I think) operates a tunnel broker for its customers and
hands out a /60 prefix on request. I heard it recently enabled its
400th customer IPv6 tunnel.
-- Niels.
Niels Bakker wrote:
It would also be nice if operators with end users started offering
native multicast. Although the AMS-IX multicast initiative started
off with lots of enthusiasm, two years later it seems to have died
almost completely.
* pete@he.iki.fi (Petri Helenius) [Tue 09 Jul 2002, 15:27 CEST]:
Most multicast projects go this way. The reason usually being one or more of;
A) ISP's want to charge extra for multicast
B) No content is being served over multicast
C) Firewalls do not pass multicast (usually non-issue on home users)
Indeed. I'm personally most amazed that B) companies like shoutcast.com
(who must be spending fortunes on bandwidth for all their streams)
aren't pushing multicast more.
Cheers,
-- Niels.
The problem is it's somewhat futile. Even at the larger providers
there is a great deal of fear at times that Multicast will make the network
unstable. Then there is the lack of education/cost-benifit on the edges
for a lot of the smaller providers.
They aren't aware of the savings they can see, consider the
savings too small, don't know how to configure, can't configure,
break the config, etc.. the list goes on and on.
Then you get the people who are stuck with an upstream
that doesn't know how to speak multicast or operate it. If you
are a customer of (i'm using this as an example, so don't come
after me) Savvis or InterNap, you use them to reach the "big"
folks. If they don't have multicast enabled you don't have
many choices unless you talk to someone who doesn't mind
unicasting you a multicast tunnel, or go the commercial
route ala multicasttech.
Then you do have the above 'firewall' issue to
contend with also, as well as other minor
misconfigurations ... such as enabling igmp
snooping on your switches can make multicast not
work right.. some switch vendors ship this as a default
setting..
Just a few of the barriers involved. I do encourage
people to contact your upstream, enable multicast, at least
speak mbgp to them and advertize your prefixes. Enabling pim
or (msdp if necessary) can be done at a later date and
doesn't require a bgp session flap. Contact your peers,
ask them if they do multicast. I've seen the number of
peers that have multicast enabled increase over the past year.
- jared
In a message written on Tue, Jul 09, 2002 at 10:39:35AM -0400, Jared Mauch wrote:
They aren't aware of the savings they can see, consider the
savings too small, don't know how to configure, can't configure,
break the config, etc.. the list goes on and on.
Speaking from a provider who used to run multicast, and now doesn't:
Customers don't want it.
I can count our customer requests for multicast on both hands for
the last two years. Of those, only one thought it was important,
the rest were just playing with it. In fact, pretty much the only
place we see it anymore is on RFP's from educational groups.
My own view is that customers don't want it, because end users
don't have it. Dial up users will probably never get multicast.
So that leaves Cable Companies (good luck for them to do something
intelligent) or DSL providers (perhaps they might) to make it
happen. If a few million end users could just 'get it', then people
running streaming services would be beating on backbone providers
to carry it around.
There is also a payment problem. If a unicast bit enters your
network, you can be assured it takes one path to the destination.
When a multicast bit enters your network, it could take one path,
or it could take 50 paths through your network. The latter does
cost the ISP more. This also makes peering an issue, as many people
use ratio. If there was a significant amount of multicast traffic,
hosting ISP's would send end-user ISP's one small stream that they
would then replicate. That would pretty much make the ratio
completely opposite of what it is today, due to unicast streaming.
I'll be the first to jump on the multicast bandwagon, but I don't
work for an eyeball provider. The first adopters need to be DSL
and cable modem providers, to the end user, on by default. Then
we can go somewhere.
Yahoo/Broadcast.com pushed this pretty heavily. MS's own media player
supports multicast, so there definitely a *lot* of clients out there.
http://broadcast.yahoo.com/home.html
There are a list of providers supporting multicast in conjunction with
Yahoo/Broadcast.com found at:
http://www.broadcast.com/mcisp/
I see quite a few cable and dialup providers on there ( and I work for
one of 'em... )
To find out if you are viewing via unicast/multicast in Windows Media
Player, the option is View->Statistics, then in the Network section...
-Chris
In a message written on Tue, Jul 09, 2002 at 10:06:10AM -0500, Chris Parker wrote:
>My own view is that customers don't want it, because end users
>don't have it. Dial up users will probably never get multicast.Yahoo/Broadcast.com pushed this pretty heavily. MS's own media player
supports multicast, so there definitely a *lot* of clients out there.
There is a lot of client _SOFTWARE_ that supports it. There are very
few clients on multicast enabled networks.
There are a list of providers supporting multicast in conjunction with
Yahoo/Broadcast.com found at:http://www.broadcast.com/mcisp/
I see quite a few cable and dialup providers on there ( and I work for
one of 'em... )
It's a cute list. Where's AT&T (with all the old @Home customers)?
Where AOL? Don't see UUNet either.
Almost as important, people like Sprint are on the list. Last I
checked (admittedly, over a year ago) there was no multicast for
Sprint DSL customers, and Sprint high speed customers had to
specifically request it, it was not turned on by default. Result,
less than 1% of Sprint's customers actually had it turned on, I
believe.
I'd be suprised if 1% of _residential end users_ were on multicast
enabled networks today. Very surprised.
* bicknell@ufp.org (Leo Bicknell) [Tue 09 Jul 2002, 16:52 CEST]:
I'll be the first to jump on the multicast bandwagon, but I don't
work for an eyeball provider. The first adopters need to be DSL
and cable modem providers, to the end user, on by default. Then
we can go somewhere.
And when approached they'll claim that it'll melt their infrastructure -
and they'll be right in a lot of cases. PPPoE and multicast still
causes a traffic explosion that multicast was supposed to remove.
When I was employed by a company deploying FTTH our vendor was working
on a hack they named "multicast VLAN" to avoid a similar situation.
No idea if they ever finished it (they weren't too keen with making
deadlines, in my admittedly short-lived experience).
-- Niels.
UUNET supports multicast, although the quality of that experience
for me wasn't very good. Last I heard its one price to receive
multicast and additional to generate multicast through them.
John
Hi
quick question. how much actual traffic are operators seing from
ipv6-enabled networks? whether native or 6to4.
i.e. if you take the average amount of data sent/received per node,
whether per protocol or per OS, how much of it is able to use V6 currently?
i still find some of the stuff extremely user-unfriendly (winxp) for
manual native configuation, and i'm sure other users do too. also, the
amount of support for it is still sketchy (whether in the transport or
from the applications themselves).
Regards
--Rob
In a message written on Tue, Jul 09, 2002 at 10:06:10AM -0500, Chris Parker wrote:
> >My own view is that customers don't want it, because end users
> >don't have it. Dial up users will probably never get multicast.
>
> Yahoo/Broadcast.com pushed this pretty heavily. MS's own media player
> supports multicast, so there definitely a *lot* of clients out there.There is a lot of client _SOFTWARE_ that supports it. There are very
few clients on multicast enabled networks.
I've got a couple million... not that many use it, though.
> There are a list of providers supporting multicast in conjunction with
> Yahoo/Broadcast.com found at:
>
> http://www.broadcast.com/mcisp/
>
> I see quite a few cable and dialup providers on there ( and I work for
> one of 'em... )It's a cute list. Where's AT&T (with all the old @Home customers)?
Where AOL? Don't see UUNet either.
I didn't say it was ubiquitous. While some are notably lacking, you
do have some larger networks on that list. Note this is also just
partners/peers with Yahoo/Broadcast, not everyone who supports
multicast on their networks.
Almost as important, people like Sprint are on the list. Last I
checked (admittedly, over a year ago) there was no multicast for
Sprint DSL customers, and Sprint high speed customers had to
specifically request it, it was not turned on by default. Result,
less than 1% of Sprint's customers actually had it turned on, I
believe.
I'd be suprised if 1% of _residential end users_ were on multicast
enabled networks today. Very surprised.
It may be a bit higher, but the number who access multicast content
is decidedly tiny. More content would probably push it higher, as
much fun as it is watching the ISS live on Nasa TV, it does get a
bit dry.
-Chris
> http://www.broadcast.com/mcisp/
>
> I see quite a few cable and dialup providers on there ( and I work for
> one of 'em... )It's a cute list. Where's AT&T (with all the old @Home customers)?
Where AOL? Don't see UUNet either.Almost as important, people like Sprint are on the list. Last I
checked (admittedly, over a year ago) there was no multicast for
Sprint DSL customers, and Sprint high speed customers had to
specifically request it, it was not turned on by default. Result,
less than 1% of Sprint's customers actually had it turned on, I
believe.I'd be suprised if 1% of _residential end users_ were on multicast
enabled networks today. Very surprised.
Speaking as the person who got Voyager.Net on the list,
here's what the deal was at the time (~2+ years ago)
You configure a tunnel between you and the broadcast.com
folks and speak mbgp+msdp over it to get their (S, G) state info and
traffic.
They gave information on how to enable the dialup ports,
etc.. for multicast.
We did have a few customers complain "what's this 224 crap traffic
you are sending us".
The broadcast.com people didn't seem to want to help
bridge the native gap between upstreams and the edge customers.
Providers I know have multicast enabled and available for
customers in some way/shape/form:
CW, GBLX, Sprint, Qwest, UUNet/UUCast, Verio
It's my understanding that Sprint has enabled pim on all
customer-facing interfaces and is configured for nlri unicast multicast
on all their bgp sessions so once a customer toggles their end to
unicast+multicast they can get mbgp prefixes. I do suggest getting
your routes in the table, which will not cause instability then later
look at/concentrate on the rest, pim, msdp, etc..
- Jared
i still find some of the stuff extremely user-unfriendly (winxp) for
manual native configuation, and i'm sure other users do too. also, the
amount of support for it is still sketchy (whether in the transport or
from the applications themselves).
Yes, after trying to help a friend get IPv6 running on his WindowsXP
system (you have to drop into a DOS box.. (but they did away with DOS,
right?)), he decided it wasn't worth it if he had to do it that way.
At some point M$ might make it user friendly for the windows users but
at this point it's /not/ something that joe blow customer will be doing.
These are two seperate issues. One is, should you base your hardware choice
on V6 support? The other is, will there be a mass rollout of v6 in the
2004-2005 time frame?
The first issue is specific to your network, but I suspect it's a low
priority for most. As far as a mass rollout of v6 - I'm not holding my
breath, 3G or not. I suspect that v4 is here until we run out of address
space, and from all indications, that is not happening any time soon.
Foundry, in particular, has always tended to be very customer-driven in
their feature sets. I suspect any support for IPv6 on their platform would
be greatly dependent on customer requirements.
Thanks,
- Daniel Golding
These are two seperate issues. One is, should you base your hardware choice
on V6 support? The other is, will there be a mass rollout of v6 in the
2004-2005 time frame?
If you are selecting a new core router today, I would base it on
support for v6. That won't be the only thing, but one should keep it in
mind as you select a router/vendor. Make sure they haven't lost sight
of all the emerging technologies you may need/want to run in the
next 2-3 years.
The first issue is specific to your network, but I suspect it's a low
priority for most. As far as a mass rollout of v6 - I'm not holding my
breath, 3G or not. I suspect that v4 is here until we run out of address
space, and from all indications, that is not happening any time soon.Foundry, in particular, has always tended to be very customer-driven in
their feature sets. I suspect any support for IPv6 on their platform would
be greatly dependent on customer requirements.
- Jared
Chris Parker wrote:
It may be a bit higher, but the number who access multicast content
is decidedly tiny. More content would probably push it higher, as
much fun as it is watching the ISS live on Nasa TV, it does get a
bit dry.
I think this is a case of "if you build it, they will come".
RealPlayer's default configuration is to first attempt to use multicast, then fail-over to UDP, then fail-over to TCP. In other words, if multicast is available, the program will use it.
I don't know about other streaming clients, but I would guess that others would behave similarly.
-- David