There are essentially three classes of network actor: client, server and peer.
In any given interaction there is always an initiator and a responder. In most
cases these correspond to the client and the server. In a peer-to-peer
application a given machine may be either an initiator or a responder.
As you imply, at the IP layer the few in common use are: unicast flow initiator,
unicast flow destination, and multicast group (anycast in the typical use being
a
mechanism to select which instance will be the unicast destination for a
specific flow).
The difference between "peer" and "server" as unicast flow destination is zero.
Unless you mean peer in some specific sense, like a participant in a DHT-based
overlay topology, as the sip p2p working group is aiming for? If so, is there
something about the overlay traversal that you believe will affect the v4
distribution? (At the moment that group is discussing reusing mechanisms
like ICE and STUN for setting up the traversal in the presence of NATs).
Now lets look at what the typical consumer does and does not want to put on
the Internet. They do want to run peer-to-peer applications. They do want to
run client applications such as the Web. Very few want to host servers and
many explicitly do not want the inherent exposure that opening a server port
entails.
First, I think making judgements about what the typical consumer will want in
the future based on the existing situation is pretty limiting, if not downright
likely
to crack your crystal ball. Aside from "more and cheaper", few such predictions
are likely to be right.
I also think by making the distinction "server port" you are going past what
the typical
consumer wants or understands. If a company provides a mechanism that allows
them to do X in some environments but not in others, it will be perceived as a
flaw. The music sharing built into iTunes is a case in point. It provides
a mechanism that allows people to stream music from their collection to some
set of other people. The restrictions to a subnet were, from the lay
perspective,
perceived as just so much jargon. You and I may recognize that making
the connection work through two NATs is non-trivial, but the "typical consumer"
doesn't in my limited experience seem to know or care. They want X to work,
and they don't see X in boxes like "client/server, peer, other".
If we can satisfy those users needs with the 50% of the IPv4 address space
that gives us the other 50% of the address space to meet the needs of the
other 5%.
I guess I missed the how of this, in a world where peers routinely want to open
unicast flows to a potentially unbounded set of destinations (other peers).
Or do you believe the peer network mechanisms at hand (like using public-IP
peers as "supernodes") scale well enough to make this work?
Don't think of it as NAT, think of it as a specialized form of IP header
compression within a network that just happens to map IPv6 space to a 32 bit
address space that may or may not be the IANA regulated one.
You had mentioned that your vision was closer to the second scenario I put
forward.
That scenario was
The second is that you mean that any device
which serves as an intersection point between v4 and v6 must
also serve as a back-to-back user agent for all applications
that run across it.
That seems to me a good bit more than specialized header compression.
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf