[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by relying on migration to IPv6



I am reluctant to reply to the group as this isn't really on topic for RRG. However, yesterday's discussion also ended up in this territory so we may as well finish what we started...

[Please note I wrote part of this message on saturday, not updating for drafts posted in the intermediate]

Client-server protocols
are very easy to translate when the clients are on IPv6 and the servers on IPv4, the only issue is with peer-to-peer protocols that require each
peer to be reachable for every other peer.

OK - I guess the IPv6 browser would use some kind of HTTP proxy or
ALG which has IPv4 address space.

Full disclosure: together with some others, I've been working on a new incarnation of the NAT-PT mechanism that translates from IPv6 to IPv4. (We call it "NAT64" along with "DNS64".) Using this mechanism IPv6 hosts can initiate TCP sessions towards IPv4 hosts and UDP packets can flow in both directions after the IPv6 host has sent the first one.

The draft should be out any day now.

Apart from that I advocate using an HTTPS proxy as a transition mechanism because it can proxy TCP sessions regardless of the appliction and regardless of the IP version the client and the server use as long as the proxy is dual stack. An HTTP proxy is of course also useful but limited to just HTTP.

Many peer-to-peer protocols have to fight their way out from NAT.  I
figure they have a lot of hard-coded IPv4 IP address stuff in them,
and there's no way this can be handled by proxies, ALGs etc. to
connect to IPv6-only hosts.

Let's address SIP and BitTorrent as the examples of the two classes of peer-to-peer applications. The IETF BEHAVE wg has come up with a fairly robust system to conquer NATs with SIP in mind: ICE, along with a set of requirements for NATs. As long as at least one of the peers is behind a BEHAVE-compliant NAT (or several of them), both sides implement ICE and there is a "coordination channel" between the two peers, the peer-to-peer communication is possible. So SIP-type peer-to- peer (where you want to be able to talk to ALL peers) is in good shape.

BitTorrent can't easily use ICE because BitTorrent doesn't allow for peers to coordinate their efforts to connect to each other. However, with some changes on implementations (not the protocol) a BitTorrent client behind a NAT, including one behind a NAT64, can receive incoming sessions if the NAT is BEHAVE-compliant.

But none of this is too big of an issue, because BitTorrent-type applications don't require that every peer can talk to every other peer. As long as there is a decent number of dual stack peers there can also be v4-only and v6-only peers and everything works. Note that in practice, BitTorrent trackers don't allow IPv6 peers to get their IPv6 address through to other peers, but the latest implementations support a dynamic hash table based system to find peers without help from the tracker and this works well for IPv6 - except that connections to IPv6 peers tend to fail in most cases... I guess there is firewalling involved here. But even today, I regularly talk to BitTorrent peers over IPv6.

As I wrote earlier, I can't imagine how ordinary Internet users
could tolerate the limited utility of an IPv6-only service

Simple: IPv4 gets worse as it becomes harder to find addresses to connect new users / services and NAT increases, IPv6 gets better as implementations mature and it's more widely deployed. Not-so-good IPv4 + not-so-good IPv6 is certainly better than either on its own, and at some point IPv6 on its own may be sufficient for some types of use.

You have to realize that except for HTTP(S) which is easily proxied, most applications only talk to a fixed server. So with an HTTP proxy and your mail and IM etc servers on IPv6 you can get a LOT of work done without IPv4.

Widespread dual-stack IPv6 and IPv4 adoption would provide no
benefit to the IPv4 scaling problem and would surely cause
unacceptable complications for end-users, their applications, high
levels of support calls to ISPs etc.

Yes, and if you don't leave the house you don't have to pay high petrol prices and the risk of car accidents is reduced by many orders of magnitude. IPv4 is heading towards a brick wall, life is going to get more complicated, there is no way around that.

Then again, we still have a billion unused IPv4 addresses. It's no use
complaining that nobody buys umbrellas when the sun is shining.

As I wrote in other messages there is plenty of scope for greater
utilisation of IPv4 addresses

If you're chased by a lion it's a good idea to run faster. But when you plan a trip to Africa, you'd probably be better off with better anti-lion protection than good running shoes.

Better IPv4 utilization is a dead end. If you absolutely need to delay the inevitable it can make sense, but you need to move to IPv6 at some point anyway, so basically any effort to keep IPv4 running longer is money down the drain.

especially with map-encap - and
continued or greater use of NAT.  So I can't foresee a time in the
next decade or so when IPv4 space will be so unavailable that it
would be easier to put users on IPv6-only, with all its limitations.

That would sound more convincing if we weren't burning up 150 - 200 million new IPv4 addresses every year.

So? AFAIK, these online games cost something like $10 a month. As soon
as the number of users that only have decent connectivity over IPv6
rises to even a few percent it's worthwhile to make these updates.

As argued above, I don't foresee when large numbers of users will
have IPv6-only connectivity.

Note that I was talking about only having DECENT connectivity over IPv6. They probably still have IPv4 but optimized for HTTP.

Any of the map-encap schemes will make it easy and cheap for 1, 2,
4, 8, 16 etc. IP addresses to be used by any end-user network.

Who cares? That just means that you can move to another hosting service without touching your DNS records. I have a private server hosted somewhere. I have the .1 address. The .2 address belongs to someone else. Keep counting a /18s worth. Basically what this will do is make the minimum usable address block 16 - 256 times smaller. But "only" 135k people are advertising a minimum sized block today. That's only a /7. Freeing up 255/256th of a /7 is barely worth the effort and much more easily done by reclaiming a few of the 10 /8s the US government has, which aren't even all announced in the routing system.

Really, this "prefixes will get longer as IPv4 runs out" idea has no merit, neither as something to work towards nor as something to protect against. Yes, deaggregation will continue but not in a radically different manner than it has the past years.

How could this impasse be broken, as long as IPv6 doesn't provide
anything new and useful for large numbers of ordinary end-users?

As soon as you need IPv6 for just one little thing that means you'll have IPv6 connectivity which can then be used for other things as well. If IPv6 is sufficiently easy to get then it's a very good mechanism to work around NAT because it allows arbitrary numbers of systems to be reachable from the outside world at a well-known address/ port, while with NAT that usually requires per-host/service settings.

It is another thing entirely to make an IPv4 application (initially
few will be written to work with IPv6) run in a host with IPv6-only
connectivity and then have it work via some ALG which itself must
have IPv4 addresses.   That would be difficult or impossible without
rewriting the protocol.

Forget ALGs. They're only needed for legacy stuff.

The v4-v6-v4 stuff is actually not all that hard. Either you translate to IPv6 with SIIT and then back to IPv4 with NAT-PT/NAT64 or you tunnel. Because you're only talking to IPv4 destinations the problem with general IPv4->IPv6 translation that you can't express 128 bits in 32 bits doesn't occur.

Furthermore, there is a profound limit to innovation here: any new
or emerging protocol would be useless until the developers made it
amenable to IPv4-IPv6 ALG, PNAT or whatever *and* had reliable code
to do that installed in all the world's ALGs, PNAT boxes etc.

The BEHAVE NAT work has advanced sufficiently that if a NAT behaves somewhat reasonably (and many already do) and the clients support some extra stuff (ICE) these problems largely go away.

Again, every IM protocol would need to be universally supported by
the world's IPv4-IPv6 ALGs etc. before it could be usable

Didn't you read what I said? I can use Google Talk (or any other Jabber based IM) through a translator TODAY with the client that comes with my OS. Actual IM (not file transfers and audio/video) is client/server so it works without trouble.

But wouldn't a BitTorrent program on an IPv6-only host be limited to
talking to other programs with IPv6-only, or dual stack, access?
That would greatly limit the scope of the programs.

Yes, and mostly no. I only talk to the IPv6-capable peers, the IPv4- only peers only talk to the IPv4-capable peers. In the venn diagram you'll see they overlap in the form of the dual stack peers. Basically you only need to get one copy of the file from the IPvX-only part to the dual stack part and you're in business. This will start working reliably with only a few percent dual stack peers.

How do you use an application which is only written for IPv4 (as
many are) on an IPv6-only host?

First you translate to IPv6, then back to IPv4 again.  :-)

Can you point to some examples?

No.  :-)

The run-out of fresh blocks of
IPv4 space is the only thing on the horizon which might prompt IPv6
adoption.  However I believe this won't be anything like a strong
enough reason to make the leap to a new, incompatible, largely
separate, IPv6 Internet

Well, either we need it and therefore we start using it, or we don't and therefore we don't. In both cases there is no problem.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg