Not something I'd typically use this list for but I have an opportunity to host a debate of sorts on IPv6 where I'm taking a very pro IPv6 stance and I need someone who wants to argue the other side - effectively that most people don't need to worry about it for a long time still or until someone makes them.
Any takers feel free to ping me directly...
Thanks,
Josh
i'm an IPv6 pragmatist. I've used IPv6 from its very beginings.
i am not a zelot, like so many are. IPv6 has its uses - but most of the
actual value in IPv6 has been stripped. for most practical, current use,
IPv4 will meet your needs now and for the forseeable future. NAT is your
lifeline here.
IF (a big one) there are actual changes in regulatory models, transmission
models, and reduced dependence on centralized control, IPv6 has a chance to
shine and truely become the "next generation". Until then - same old, same old...
96 more bits - no majik.
--bill
well, i've argued new gtld registry operators in general do not benefit from a manditory v6 reachability requirement at transition to delegation, a position unpopular with v6 evangelicals and others who suppose that new gtld registry operators will exist to serve "the next billion users" rather than to offer alternate name space views to the existing {b,m}illions of v4 addressed spindles.
related, i've argue that new gtld registry operators in general do not benefit from a manditory dnssec requirement, a position unpopular with dnssec evangelicals and others who suppose that new gtld registry operators will exist to serve ecommerce with sufficient generality, persistence, and volume to make them more attractive targets for rational economic exploits than existing, unsigned zones.
for those not keeping track, icann's laundry list of mandatory to implements includes v6 reachibility, and dnssec, shortly after the date of contract, so significantly prior to the operator acquiring operational experience, and of course, cctlds, and existing gtlds, are under no obligation to sign their zones.
i don't think of these positions as "naysaing" either v6 or dnssec, just the it-must-be-done-now claims of urgency and universality of some of the respective advocates for "sensible stuff", who because they hold the right opinion, inform icann's ssac.
-e
IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently (again mainly a DSL problem where TR-069 isn't in use), and the requirement to replace PPPoE/oA termination gear (like Redback SMSs) means that a small telco (say 3000 DSL lines) could be facing a multi-million dollar expense to enable IPv6 for customers.
For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.
according to the
vendors selling CGNAT solutions the impact to end users is (almost)
unnoticeable.
And according to a used car salesman, this here pickup truck was only gently driven by a little old lady to the shop once a week. There's going to be a lot of snake oil in the next couple years as very small ISPs struggle to implement native IPv6 over those aging DSLAMs and GPON systems that don't and won't support it.
Nathan
Scott Helms <khelms@ispalliance.net> writes:
IPv6 for some ISPs will be extraordinarily painful because of legacy
layer 2 gear
I don't feel sorry for them. We know that IPv6 is coming for how long?
15years? 10year? 5years? Well if you only read the mainstream media you
should have read something about this new Internet thing about two years
ago. And still many people fear IPv6 or think the can still wait for
another couple of years.
For ISPs in this circumstance the choice will be CGNAT rather than IPv6
for a number of years because the cost is much lower and according to
the vendors selling CGNAT solutions the impact to end users is (almost)
unnoticeable.
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
LOL just try your cell phone... Mine works fine over office wifi but not over cellular. Its not just small ISPs; its tier1's as well.
Tom
Oh, that's not the WORST of it.
... 3+ years ago ...
IPv6 is coming. All gear needs to support it. Here are the basic models of security from the router that we can use and pros and cons for each. You do NOT want DSLAMs which enforce their own security.
... each year after ...
*repeat*
... 1 year ago ...
Engineer: I disapprove of that DSLAM. It has IPv4 security measures you can't disable (PPPoE and DHCP security! Wow!), doesn't support enough q-in-q support to use an isolation model, and doesn't have IPv6 support itself to make up for what it breaks.
Telco: Well, we're buying millions of dollars worth, so we'll just have to make it work. Vendor says it'll be IPv6 ready later this year.
... 1 year later ....
Telco: Why did we do this? They say it will be ready later this year. The problems we've had with this vendor have been awful. We should have used someone else.
Engineer: No worries. I'm sure they'll get the support ready for you in time. I'll have my side sitting here waiting on them or worst case you'll spend some money to work around/replace them.
*snickers*
Jack
http://bill.herrin.us/network/ipxl.html
Joking, but only half joking.
What kind of debate? Live debate doesn't work for me; I have the
answers 15 minutes later. Personally, I'm leaning IPv6, but I can tell
you the arguments opposed....
* Timing means we have to do carrier NAT anyway. Why go to both expenses?
* Carrier NAT buys us enough years to build an IPv4 successor that
actually solves some of the intractable IPv4 problems. Deploying IPv6
as it exists today requires massive amounts of manpower yet solves
none of IPv4's problems save for the larger address space. Worse, it
even doesn't appear to create the opportunity to solve those problems.
* High disruption risk deploying IPv6 as implemented. May be smarter
to wait until we have a protocol without the design errors that make
IPv6 such a high deployment risk.
* Will have learned enough in an aborted IPv6 transition to do the
next one with minimal disruption. Things like host and network level
configuration of protocol priorities so we have a better ability to
stagger the cut-over process.
* IPv6 remains half-baked with key technologies like enterprise NAT
missing from the products. It isn't really ready for wide deployment;
it's only being driven by IPv4 address exhaustion -- which we can
defer for a couple decades through carrier NAT and other address
reclamation enablers.
* Next protocol should really be designed to support interoperability
with the old one from the bottom up. IPv6 does not, requiring
expensive and indefinite dual stack.
* Can solve the multihoming/mobility problems we see in v4 if we ditch
TCP with the next protocol and build something with multilevel dynamic
addressing at the heart. Those problems remain intractable if we
don't... and for IPv6 we didn't.
and so on.
Anyone care to define CGNAT? Google results for this are either unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no explainations, nothing....
I don't know. We're pretty far down the road now, but there might be things
that could have done with NAT/PAT to make them suck less, at least for
eyeball networks. Just being the devils advocate here. What if dynamic
address assignment by eyeball ISPs had been modified to allow a "fractional"
IP address reservation. 1/2 IP, 1/4 IP, ..., 1/16 IP, down to maybe 1/256
IP. Each one would represent a range of ports, dividing up the available
port range in 2^k pieces. This wouldn't really represent a layer of NAT,
just an agreement by the CPE device to only use a specific range of ports
within the assigned routable IP address (this is the fractional IP part).
Of course, the upstream router could enforce that port restriction. The
"low" fraction in each IP would tend to have the standard server ports
available, so one server on standard ports could be accomodated per routable
IP, but eyeball boxes shouldn't care that much, and everybody would have a
fixed port range, so P2P services that are port flexible could still have
ports to map in through. Ok, it's kind of ugly, but the PC's inside it
wouldn't feel much worse off than they do today. the CPE could even map
static ports all the way through to pc's on the lan...
And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support.
CGNAT, CGN (carrier grade nat, technically a marketing term), LSN (large scale NAT), NAT44[4..]....
Jack
* 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? And yet there's still all kinds of stuff that isn't really ready for prime time yet.
* 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. A system that knows about 32-bit addresses will just not talk to a system with a 128-bit address. Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. But then, 32-bit ASes interoperate with 16-bit ones with no trouble and still after a decade the support for that is not nearly good enough, either.
Supply and demand. There was no demand (most of my vendors didn't get any requests/questions concerning IPv6 until roughly 6 months ago). J and C have had considerable support (though still a work in progress) for some time, though I'd agree that 5 years sounds about right (it takes 1 large core network to push C/J into implementing base IPv6, but it was originally around that customer's desires and not multipurpose).
Jack
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. 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? Was the right equipment even available for a production environment?
Not only that, but cheap CPE equipment that supports IPv6 still hardly exists today, and all of that will need replacing. 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?
No, IPv6 rollout is going to be extremely expensive and will likely put a number of smaller operations out of business.
david raistrick <drais@icantclick.org> writes:
And at what point during that time did they have any vendor gear they
could purchase that -would- support v6? At -best- during the last 5
years, but I'd put money on that even today they can't purchase gear
with adequate v6 support.
Another chicken and egg problem here. Customers have no demand for IPv6,
vendors don't implement it. Vendors don't implement it, customers don't
use it.
Sad but true. Right now I have two TAC request open with Cisco
regarding IPv6 problems on the ASA. Ever tried traceroute to a
dual-stacked or IPv6 only host? 
Jens
BTW: No need to cc me I'm reading the list.
IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently
[...]
For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.
The good thing is that as an ISP, you don't have to give everyone the same thing. For the content people, it's either an AAAA record in the DNS or no AAAA record in the DNS. But as an ISP, you can keep your existing customers on existing IPv4 using existing hardware, while you roll out CGNAT + IPv6 for new customers using new gear. (Yes, that's still going to be annoying, but annoying in the sort of "I wish I didn't have to but I guess I do" kind of way rather than the "this will bankrupt the company" kind of way.)
As long as your "legacy" users have an IPv4 address they can always use tunneling to get IPv6 (you may want to set up a tunnel termination box for this) if they need IPv6. But they won't really _need_ IPv6 (at least not very soon) because they can set up port mappings etc and everything they need can work over IPv4.
For the new users, there are no port mappings behind the CGNAT so they do need IPv6 for hosting services and for VoIP and peer-to-peer file sharing. They also can't get a protocol 41 tunnel so you, their ISP, has to provide them with IPv6.
But just CGNAT with no IPv6 is going to be very bad. Maybe 95% of your users won't notice, but do you really want the other 5% to tie up your support lines?
I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but
when did 7 happen?
There's a Google hit on Tim Wilson posting about IPv4 replacements in
an informational RFC from 1993 using IPv7, but that's all I found.
Ultimately vendors only kneejerk when they're told to kneejerk.
It's not like we didn't know about it 10 years ago too, but when
the feature mill was prioritized... around the merry-go-round we go.
So let's lay blame where everybody can agree: suits.
Mike