Subject: RE: why market picked up NATs [Re: Writeups on why RFC1918 is bad?]

From: "Tony Hain" <[email-masked]>
Date: Mon, 27 Oct 2003 21:41:42 -0800

I now have time to catch up transiting back & forth to jury duty for the
next few weeks.

On Monday, September 22, Erik Nordmark wrote:
> Pekka,
>
> I think there is an overarching issue about deployment/transition
> that relates to the NAT thing;
> providing a new service/feature/capability by only adding one box to
> the network is a lot easier sell than for instance
>  - requring a box in the peer's network
>  - requring all the routers in the path to do something new
>  - requring the ISP to do something new
>
> Thus even though NATs cause lots of problems, many would be swayed by
> the low entry cost of just adding a box to get some particular
> new capability.
> And NATs are used as a technology as part of providing different
> user visible capabilities such as
>  - "connection sharing" from home
>  - load balancers (without needing any support in the servers
> behind the LB)
>  - multihoming boxes (some combining NAT and a DNS server for inbound and
>    outbound multihoming support without ISP involvement or host awareness)
>
> It isn't clear to me at what point the pain caused by NAT in
> different cases
> will be high enough to motivate a transition to some different
> technology, or
> whether there must be new capabilities (such as the ability to have
> multiple servers at the same port number in a home) that are perceived
> important enough to cause migration away from NAT solutions.

While your earlier comments start addressing it, this last comment clearly
misses the point, and is consistent with Geoff's issue that technologists
dont' grok market economics. The market doesn't pick technology for
technologies sake, it picks tools that solve an acute problem. This means
that nat will be with us until it becomes part of the problem that needs
solving. Consumer friendly p2p is the obvious catalyst, so the answer to
your 'at what point' question becomes, when there are applications that
consumers want to deploy.

Tony

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Wed, 29 Oct 2003 10:16:20 -0800

Tony,

>> Michel Py wrote:
>> Note that p2p is not that unfriendly as of now. I just had a
>> look at one of the pieces of p2p I use at home; there are some
><                              ^^^ 
>> 230k users on the server I connect to, 
>>                   ^^^^^^

> Tony Hain wrote:
> And the inconsistency with that statement is???

There is not any. Most p2p software relies on some kind of
(de)centralized infrastructure. Napster did, it was centralized, that's
how they shut it down. Even threedegrees does; even if you remove the
Teredo infrastructure there still is a centralized component: where is
the list of rooms kept?

P2p apps still need a mechanism to locate each other. This is even more
important with IPv6 where random scans to find who is running the same
app are doomed to fail because of the 64-bit IID.

What has changed since the Napster days is that rendezvous points are
now more distributed than they originally were. This has everything to
do with legal issues and nothing to do with technology. Nevertheless,
the best search results are still obtained when a few powerful machines
that can handle a large search table are available. The notion of p2p is
that _after_ two hosts found each other, they are able to talk directly
to each other without relying on any kind of infrastructure; p2p does
not mean "no infrastructure whatsoever". The infrastructure has nothing
to do with traversing NAT; for that one app I still have to open the
port in my router.

For your curiosity here is a screen shot:
http://arneill-py.sacramento.ca.us/emule.jpg

P2p does not only mean files either. I consider SIP a p2p app. Well,
even if in theory I could dial another SIP phone directly, I don't
(partly because dialing the IP address and port is ugly, partly because
the destination address might change). I use a centralized directory
service (http://www.pulver.com/fwd/index.html)

My point was, given the large numbers of people using such things,
joe-six-pack is now able to configure his Linksys to open the p2p app
port or the SIP port. The argument that NAT breaks things does not hold
water when I see 1.45 million users using the same p2p app at the same
time I am using it. 

Oh, I have news for this WG too: out of these 1.45 million p2p users,
1.45 million do not give a rip to IPv6.

Michel.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Oct 2003 14:26:44 -0800

> Teredo infrastructure there still is a centralized component: where is

Threedegrees does not use a central service to maintain the list of user
groups or musicmix sessions. The groups have unique names, basically
large random numbers that are only known by the group members. The name
space is managed by a distributed application, PNRP. You can get more
information at www.microsoft.com/p2p.

Threedegrees is however tied to MSN Messenger, which uses a central
service to manage the presence application.

> app are doomed to fail because of the 64-bit IID.

In the case of PNRP, a node needs to find at least one member of the
"cloud" in order to bootstrap. We use persistent caches and local
multicast, which works in many cases, but we ultimately rely on a "seed
server" to connect participants to the PNRP cloud. The seed server is
used for initial contact, and does not hold actual data. 

> that can handle a large search table are available. 

You are confusing discovery and naming. Doing discovery by trying a
fuzzy search over a distributed system is quite hard. Doing a direct
lookup, on the other hand, is relatively easy.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Wed, 29 Oct 2003 15:13:32 -0800

Christian,

> Christian Huitema wrote:
> Threedegrees is however tied to MSN Messenger,
> which uses a central service to manage the
> presence application.

For the sake of the argument, what would it take if you did not have MSN
Messenger (short of re-creating a centralized service that pretty much
implements the same functions)? I mean, the presence detection is
somehow like a dynamic DNS mechanism: when the app comes up it registers
with some kind of a centralized entity, even though that centralized
entity might be distributed.

> In the case of PNRP, a node needs to find at least one member
> of the "cloud" in order to bootstrap. We use persistent caches
> and local multicast, which works in many cases, but we
> ultimately rely on a "seed server" to connect participants to
> the PNRP cloud. The seed server is used for initial contact,
> and does not hold actual data.

So, the first time the app connects, or the apps that connects after
being off-line for a while has reasonably good chances to need the seed
server.

> [snip]

Thanks for the precisions.
 
Michel.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Oct 2003 18:31:54 -0800

> entity might be distributed.

You can certainly do a distributed implementation of an IM+presence
system. If I understand correctly, that is what more or less what Skype
is doing.

-- Christian Huitema