From: Ted Hardie [mailto:hardie(_at_)qualcomm(_dot_)com]
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.
It is as far as the network layer is concerned.
A client server interaction is mediated through the DNS exclusively.
A peer-peer interaction is typically mediated through DNS and a broker in
combination. In the case of peer-to-peer messaging that is through SIP.
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).
That is a logical approach if you assume that the NAT people insist that the
net work around them.
But the NAT folk are more than willing to meet in the middle. There is a
potential win-win here. The NAT folk can avoid the need to continue to build in
work-arrounds into their product and application designers can build to
something that can be expected to work interoperably.
All we need to do is to make the NAT a little less unpredictable.
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.
Such predictions only need to hold until we arrive at the world of IPv6.
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".
Exactly, there must be a branding regime so that a consumer knows that if his
NAT box has the 'It Just Works' brand that they are assured that it will just
work with Itunes etc.
If you are a consumer trying to figure out why their videocam software won't
work you are going to have a pretty ugly experience today. Even if you know
about the basic networking concepts you will find it pretty difficult with most
of the consumer oriented client to find information on the ports the protocol
expects to be able to use.
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?
I would certainly like to avoid the set of schemes that work around NAT by
routing all traffic through a nearby node that has unrestricted connectivity.
Alice calls Bob and it is routed through Carol's machine. Ugh!
Alice should be able to call Bob and the data packets travel directly from
Alice to Bob even when Bob is behind a NAT. That is possible even with IP
address pooling, all that is necessary is to configure the systems in such a
way that Bob can advertise an IP address and port number in Internet IPv4
address space that will route to the port his peer is listening to in his
NAT'ed address space.
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.
It might not be necessary to go to that level. I do think that the NAT box has
to be at least reporting its behavior at the application level. Having it act
as SIP proxy might not be the best way to do that.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf