On 27-aug-2007, at 1:48, Hex Star wrote:
There's a lot of discussion on these lists about switching to IPv6
and what technical changes/implementations will be necessary for
ISP's when the move is made but when will the move be made? Will
the move be gradual so that users who have a IPv4 modem will have
time to exchange the modem for a IPv6 compatible one? What will
happen to websites on networks that haven't yet moved over to IPv6?
In order for a session to be IPv6, all of the following must support
IPv6:
1. Web browser/client application
2. OS
3. Home gateway
4. Last mile
5. ISP backbone
6. Content network backbone
7. Firewalls/load balancers
8. OS
9. Server application
OSes, a lot of applications/servers (not all, though) and backbone
routers can all do IPv6 without too much trouble. So that leaves:
3. Home gateway
Although there are a few that will do IPv6, the popular ones don't
and there is currently no easy way to make IPv6 happen between a home
gateway and an ISP connection.
4. Last mile
The basic technology to get IPv6 packets across different types of
last mile networks exists, but I'm not sure to which degree the large
access concentrators support it. And, as mentioned under 3., there is
no clear way to provision IPv6 addresses to customers.
7. Firewalls/load balancers
Firewalls, getting there, but ultraconservative by their nature. (A
lot of them still have trouble with RFC 1323 after 15 years.) I have
no idea about the status of load balancers, but they need work, I
gather.
IPv6 support was supposed to happen in 3G wireless. I don't think it
did, at least not across the board. IPv6 support was supposed to
happen in ADSL2 modems. Again, don't think this happened. It's now
supposed to happen in DOCSIS 3 (cable modems).
In my opinion, until the IETF or an industry group comes up with
something that tells vendors on different sides of the local loop how
they're supposed to talk to each other to make IPv6 happen
automatically, not much is going to happen unless demand reaches
"riot in the street" levels. Note that all the necessary ingredients,
in the form of numerous protocols, are available, it's just not clear
which one you should use for what in which way. (This always happens
when there is a new technology: in the early days of dial-up, you
needed AT commands and login scripts and in the early days of ISDN
you had three or four different protocols, but after a few years, the
industry settled on a default choice that worked without user
intervention.)
However, there seems to be lack of a big picture view in the IETF.
For instance, you can get everything you need from PPP with IPv4, but
you currently need to run PPP with stateless autoconfiguration for
your address and DHCPv6 for nameserver addresses. But many vendors
disable the former for IPv6 and don't implement the latter. So in
practice, you can't do IPv6 over dial-up.
I expect the fact that IPv4 address space is running out within 5
years or so will be enough to push people to make progress in this
area and others, and the need to test IPv6 in various scenarios will
make sure that the protocol will be made available in more and more
places, but probably not yet at production quality.
Once the big IPv4 address crunch starts NAT deployment will go
through the roof and more and more people will either offer IPv6 or
ask for IPv6 to get around NAT. If by that time, $50 home gateways
can do IPv6, I expect ISPs, especially address starved ones, to
enable IPv6 and users will be using it without a conscious choice on
their part. At this point, it becomes interesting for the content
networks to make sure they're reachable over IPv6 too, especially
ones that need something better than garden variety client/server
TCP, i.e., video streaming. Same thing for peer-to-peer applications.
Modems that don't do IP but only ethernet don't have to be replaced
or upgraded, but anything that touches IP does.
People will continue to reach most of the internet over IPv4.
Initially through NAT, later maybe by ditching IPv4 locally and using
a proxy or translator device a bit futher upstream.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf