[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v6-v4 transition scenarios, take 1
On Mon, 28 Jul 2008, Iljitsch van Beijnum wrote:
As an observation after writing this, I'm focusing pretty much only on
client-server type applications because I've yet to see p2p or other
_inter-domain_ applications that are business critical. Another reason may
be that I don't know them in detail, and that will likely require
application-specific transition scenarios, not just ALG extensions. But
I'm willing to be convinced otherwise...
VoIP in general and Skype in particular are rapidly becoming business
critical for many people. Peer to peer downloading isn't "business" critical
but you're sure going to hear from users if you break this. (Don't forget
that web and mail doesn't sell 20 Mbps ADSL2 connections, that stuff works
fine on 1 Mbps, many users buy faster links because of the peer to peer
stuff, it's bad business for ISPs to break this.)
AFAIK, p2p protocols, at least downloading, are smart enough to work
through a NAT box that doesn't support any ALG, UPNP, port
redirection, etc. I have personal experience with this :-). So, does
this require special casing in NAT64 techniques or are such
approaches enough client-server -like?
1. ISP offers IPv6-only provisioning as a new service offering using
translation or tunneling
Due to IPv4 exhaustion (public or private space), due to alleged O&M
simplicity, an ISP prefers to provision a futuristic green field deployment
or residential or small enterprises only with global v6 addresses. This
requires customers to move voluntarily from old service
First rule of ISP operations: never, EVER make your users migrate to
something new, this costs a fortune in support calls.
I would assume all of this only applies to new customers, addresses for
existing customers won't disappear.
So, the ISP may do as they do in Finland: only provide support in a
0.39 EUR/min phone number. As a result, they're able to downsize their
support departments. Think about the revenue opportunities! :-)
The text talks about both new customers, or old ones migrating to a
new type of service voluntarily.
In addition, the ISP starts providing IPv6 service to the customers as a
way to show the users this is actually "the good thing for the continued
health of Internet".
Or they don't, because they are too busy keeping all the different instances
of the same RFC 1918 addresses straight... That would be bad.
Sure. Actually I added conditionals that take care of this in take 2.
The big question here is on whom the burden of the translation falls. If it's
the job of the greenfield people, then it's easy because they can just get an
IPv4 address (perhaps even just a port for each service on a shared address),
publish the IPv4 address and set up a static mapping.
If on the other hand the IPv4 clients must arrange for their own translation,
this means a generic IPv4-to-IPv6 NAT (NAT46), which is much tougher than the
other way around.
Agree that this is an issue, but not probably in practise. Let me try
to phrase it differently.. "I strongly encourage all my competitors to
start providing their services as v6-only".
So I don't think there should be a big question about which approach
is viable and which isn't.
4. Nearing 2015, ISP wants to ensure its users can reach all the
services in Internet, and deploys a v4-to-v6 NAT
Is it a given that NAT is the appropriate option in this case?
Many protocols support proxies, where the name-to-address translation happens
at the proxy so if the proxy supports IPv6, the client doesn't have to.
(I don't think it's a good idea to mention dates, though. It's only recently
that people have stopped whining "you IETF guys said we'd be out of IPv6
addresses by 2005 and it didn't happen".)
Maybe I should have used s/NAT/translator/, that was certainly the
intent. However, in practise given that the intent is to support
weird v4 hosts and apps in "end-game" situation, it seems improbable
that an app-specific proxying would be enough.
Wrt dates, I wanted to emphasize that this won't be happening any time
soon.
I expect once the IPv6 ball gets rolling people will start turning off IPv4
surprisingly fast.
Personally I doubt it -- a lot. Or we have a different things in mind
when we talk about "IPv6 ball gets rolling".
I wouldn't turn off v4 on any service I have association with until at
least 90% and hopefully more than 99% of the user base (or potential
user base) could reach it.
IPv4 exhaustion is not causing major problems for these applications as
these already have a pretty good NAT traversal mechanisms and those
mechanisms are likely to get better over time.
Many of the currently used NAT traversal techniques don't work well with
multiple layers of NAT, and with more users behind an IP address it will be
harder for users to open up ports to host incoming sessions. So I don't think
this is necessarily true.
I guess you're referring to NAT traversal mechanisms such as uPNP,
NAT-PMP etc. -- I don't count those as NAT traversal because they
require modifications in NATs. Teredo and similar tunneling
mechanisms which require no NAT modifications are the true traversal
mechanisms.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings