Cost's might be lower but service will be worse. NAT breaks a lot of
applications file sharing will not work properly and running your own
web server at home will not work properly. Well you always get what
you
pay for and people will buy any crap if it is cheap enough.
Jens
While that is true, it is no worse than the situation right now. In the
US, the vast majority of users are already behind a NAT (I would say
over 90% of them are) so they are already experiencing this breakage.
* Carrier NAT buys us enough years to build an IPv4 successor
You're kidding, right? How long did it take exactly to get where
we are now with IPv6? 18, 19 years?
Tech like carrier NAT theoretically yeilds address reclamation in
excess of 80%. Internet-facing servers must consume IP address. It's
convenient for client computers to do so as well, but not critical to
the general function of the Internet. 20 years is about what that
level of reclamation buys before we're out of addresses again. As you
say -- enough time to develop a protocol and get it into the software
and hardware.
* Next protocol should really be designed to support interoperability
with the old one from the bottom up. IPv6 does notThat's because it's not the headers that aren't incompatible (the
protocol translation is ok even though it could have been a bit
better) but the addresses.
No, it's because decisions were made to try to abandon the old DFZ
table along with IPv4 and institute /64 as a standard subnet mask. But
for those choices, you could directly translate the IPv4 and IPv6
headers back and forth, at least until one of the addresses topped 32
bits. The transition to IPv6 could be little different than the
transition to 32-bit AS numbers -- a nuisance, not a crisis. You
recompile your software with the new IN_ADDR size and add IP header
translation to the routers, but there's no configuration change, no
new commands to learn, etc.
Regards,
Bill Herrin
Jason Bertoch <jason@i6ix.com> writes:
I'm not sure about your part of the world, but the economy has been
terrible in mine. Even in a good economy, DSL margins don't afford the
ability to replace your network every two years.
Same thing here in Germany. DSL providers fighting for the lowest price
and customers thinking that free service is still too expensive.
In fact, spending on new gear all but halted for us over the last 6
years. While everyone is still figuring out best practices for IPv6
rollout today, how difficult would it have been to plan and purchase
the exact equipment that long ago?
Yeah. But they could have made plans and demanded working equipment from
the vendors.
Was the right equipment even available for a production environment?
No, an in some case it is still not available today.
Not only that, but cheap CPE equipment that supports IPv6 still hardly
exists today, and all of that will need replacing.
In Europe: Fritzbox from AVM. Almost all the big vendors have their own
branded version of it. And the latter versions do support IPv6 quite
well.
In addition, what about IP phones and the customer that just replaced
their entire phone system? Are they going to want to do that all over
again by the end of the year?
You don't have to replace everything at once. But you have to start
somewhere.
No, IPv6 rollout is going to be extremely expensive and will likely put
a number of smaller operations out of business.
I know several smaller ISPs which offer IPV6 for years. Sure the eyeball
providers can hardly beat the cheap prices of the big players. But they
do offer individual and good service.
Jens
There's a big difference between being able to have uPNP IGD or NAT-PMP open up holes in the NAT (or do it manually) and being 100% incapable of getting any and all incoming sessions. And between having 64k ports for a home and having 64k ports for 100, 1000, 10000 ? homes.
"George Bonser" <gbonser@seven.com> writes:
While that is true, it is no worse than the situation right now. In the
US, the vast majority of users are already behind a NAT (I would say
over 90% of them are) so they are already experiencing this breakage.
I never thought it was that bad. In some 3G/wireless networks in Germany
the providers use NAT and transparent HTTP-proxy. But this is only
wireless. I'm not aware of any DSL or Cable provider NATing their
customers.
Jens
You put your finger exactly on the reasons for advocating IPv6. If you look at the OECD report and some others...
You have to move to IPv6, not because it has new features, not because it is great, but because if you don't, you will loose your economical advantage over your competitors (and other economies).
Who spoke about the SEC requiring mandatory fillings re state of IPv6 deployment for business continuity plan requirements?
Yes, as that will cause them to produce an IPv6 product for those customers (even if it's a specialized CPE they ship to those 5% that does a tunnel back to an ISP server which connects to native IPv6).
You must have demand and pressure to push companies to spend money. Helpdesk calls count. Let the phones ring. The suits will listen then.
Jack
I never thought it was that bad. In some 3G/wireless networks in
Germany
the providers use NAT and transparent HTTP-proxy. But this is only
wireless. I'm not aware of any DSL or Cable provider NATing their
customers.Jens
Practically all broadband providers NAT their customers in the US. If
you look at the largest ones which are probably Comcast, Verizon, and
AT&T, you have the majority of US broadband subscribers right there.
Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT on large scale. Having said that almost all of the DSL customers in the US are being NAT'ed, but on the edge device (DSL modem) rather than in the core.
Practically all broadband providers NAT their customers in the US. If
you look at the largest ones which are probably Comcast, Verizon, and
AT&T, you have the majority of US broadband subscribers right there.
You mean they provide CPE which does NAT? Or the CPE actually has a
RFC1918 address on the WAN?
Are you sure about that - I'm a comcast subscriber and see no signs
that I am being natted?
Thanks,
Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT
on
large scale. Having said that almost all of the DSL customers in the
US
are being NAT'ed, but on the edge device (DSL modem) rather than in
the
core.
--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
How many instances of 10/8 did they say they were running? I was behind
a NAT when I had Comcast service. I am behind a NAT currently with my
AT&T service.
Note that the NAT was done on the "cable modem" in both cases and not
further in to their network. That said, from my reading of some
industry large scale NAT devices (the A10 AX series is one which I am
familiar with), they do things such as full cone NAT so it will still
work with many applications that might break with conventional overload
dynamic NAT.
You mean they provide CPE which does NAT? Or the CPE actually has a
RFC1918 address on the WAN?
Correct, the CPE does NAT. But regardless, the user's platform (and
hence all the applications running on it) are going through a dynamic
NAT.
Are you sure about that - I'm a comcast subscriber and see no signs
that I am being natted?
Josh, maybe it is different in different markets. When I had Comcast, I was behind a NAT.
George,
Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other defined non-routable blocks for cable modems, which (if its a DOCSIS certified device) will be a bridge only and will not do NAT. If you we're NAT'ed on a cable modem system it must have been a proprietary system, of which there once was a ton before DOCSIS caught on, that Comcast hadn't phased out.
I don't believe that any of the large MSO's (and none of the small ones I know) are doing NAT on edge devices or the core at this point, however your point is still valid since virtually all of the ADSL lines deployed are being NAT'ed at the modem level and that means that millions of people are being NAT'ed without a choice. That also means that a lot of people are already going through two NAT translations since they have plugged in a small router behind their DSL modem and both are NAT'ing their buggy little hearts out. We also have to think about the tremendous number of people on all kinds of networks that are voluntarily, like me, NAT'ing through one device of their own (usually not educated) choice.
Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other
defined non-routable blocks for cable modems, which (if its a DOCSIS
certified device) will be a bridge only and will not do NAT. If you
we're NAT'ed on a cable modem system it must have been a proprietary
system, of which there once was a ton before DOCSIS caught on, that
Comcast hadn't phased out.I don't believe that any of the large MSO's (and none of the small
ones
I know) are doing NAT on edge devices or the core at this point,
however
your point is still valid since virtually all of the ADSL lines
I can log in to the Two Wire device on my AT&T Uverse service and see
the NAT configuration. It has a global IP on the Internet side and it
has a DHCP server handing out RFC1918 addresses on the inside network.
I can also configure some settings which allow certain applications
inside to map to specific ports on the global IP.
When I had Comcast, I am not positive where the NAT was being done, but
my computer got an RFC1918 IP when it did DHCP.
You're kidding, right? How long did it take exactly to get where
we are now with IPv6? 18, 19 years?
Tech like carrier NAT theoretically yeilds address reclamation in
excess of 80%.
Most IPv4 space is unused anyway, but it's not being reclaimed much despite that. (How many IP addresses does the US federal government need? Few people would think ~ 10 /8s. Especially since many of them aren't even lit up.)
* Next protocol should really be designed to support interoperability
with the old one from the bottom up. IPv6 does not
That's because it's not the headers that aren't incompatible (the
protocol translation is ok even though it could have been a bit
better) but the addresses.
No, it's because decisions were made to try to abandon the old DFZ
table along with IPv4 and institute /64 as a standard subnet mask. But
for those choices, you could directly translate the IPv4 and IPv6
headers back and forth, at least until one of the addresses topped 32
bits. The transition to IPv6 could be little different than the
transition to 32-bit AS numbers -- a nuisance, not a crisis. You
recompile your software with the new IN_ADDR size and add IP header
translation to the routers, but there's no configuration change, no
new commands to learn, etc.
It's not that simple. But I agree on one thing: it could have been better.
What needs to be done to move from IPv4 to IPv6 is three things:
1. the headers
2. the addresses
3. the applications
Today, only IPv6 applications can use IPv6 addresses and only when IPv6 applications use IPv6 addresses will there be IPv6 headers. It would have been better to roll out the headers first. That would have meant changes to routers, because routers touch the headers. But if translating between IPv6 with 32-bit addresses and IPv4 can be done with low overhead (which is more or less the case today, BTW) then it would have been possible to upgrade from IPv4 to IPv6 subnet by subnet. This way, there wouldn't have had to be any dual stack, and once people had deployed IPv6 they would have kept using it. Today, and especially some years ago, IPv6 would/will often atrophy after having been deployed initially because of lack of use.
Apps could have been upgraded the same way they have now, with the only difference that using an IPv4-mapped IPv6 address meant generating an IPv6 packet, not an IPv4 packet as is done today. Once 128-bit addresses are being used going from an IPv6 subnet to an IPv4 subnet becomes problematic, but this can be solved with stateful translation so most stuff keeps working anyway. And remember, servers and apps that can't work through a stateful translator can still get 32-bit addresses so everything keeps working without trouble.
However, it's easy to come up with all of this in 2011. In 1993 the world was very different, and many things we take for granted today were still open questions then. It's very illuminating to read up on the mailinglist discussions from back then. People complained about IPv6 a decade or half a decade ago, too. Back then there may have been a chance to come up with a different protocol as a successor for IPv4, but it's way too late for that now.
Anyway, most non-legacy applications support 128-bit addresses now and we have a pretty decent NAT64 spec sitting in the RFC editor queue (even if I do say so myself) so it's just a matter of sitting tight until we're through the painful part of the transition.
Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT
on
large scale. Having said that almost all of the DSL customers in the
US
are being NAT'ed, but on the edge device (DSL modem) rather than inthe
core.
--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorumHow many instances of 10/8 did they say they were running? I was behind
a NAT when I had Comcast service. I am behind a NAT currently with my
AT&T service.Note that the NAT was done on the "cable modem" in both cases and not
further in to their network.
10/8 is the management network on my cable modem. The cable modem bridges your wan 'real' ip(s) through to your PC or router. At least that's how Suddenlink does it here. The customer is normally 'locked out' of the cable modem, unlike a dsl modem. The largest NATs are presumably w/mobile carriers. I've never been behind NAT (except one I controlled) on a consumer dsl or cable link in the US.
Ken
That said, from my reading of some
Most IPv4 space is unused anyway, but it's not being reclaimed much despite
that. (How many IP addresses does the US federal government need? Few
people would think ~ 10 /8s. Especially since many of them aren't even lit
up.)
What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not.