ietf
[Top] [All Lists]

RE: Peers, servers and consumers (was RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition)

2007-07-17 23:12:48

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