From: Ted Hardie [mailto:hardie@xxxxxxxxxxxx] > >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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf