[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