Subject: [p2p-sip] STUN (rfc3489)

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 30 Jun 2006 21:47:41 -0700

Thanks for the understanding.

There are different ways to say an "egg", but an egg can never become an
elk, I guess.

Classifications (terms) can change but capabilities won't.

There seems rare "sorts" of NATs behind which a node can act as SN w/o
nightmare.

Peter
----- Original Message -----
From: Adam Fisk
To: Peter Pan
Cc: Cullen Jennings ; p2p-sip at cs.columbia.edu
Sent: Friday, June 30, 2006 8:53 PM
Subject: Re: [p2p-sip] STUN (rfc3489)

My understanding is that those terms for NATs have been deemed inadequate
for describing NAT behavior in the field.  I'm not up to speed on latest
STUN drafts, but I believe Cullen's link gives the appropriate descriptions
of the newer, more accurate NAT classifications.

-Adam

On 6/12/06, Peter Pan <huang-ming.pan at comcast.net> wrote:

> On Jun 12, 2006, at 10:24 AM, Peter Pan wrote:
>
> > Is it possible to realize a STUN sever defined by
> > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can
> > discover
> > the NAT type before a STUN client?
>
> I have no idea what you mean by NAT type but if what you mean is the
> classification in RFC 3489, then NO. If what you mean is enough to
> detect connectivity such as used by ICE, then YES.

By NAT type I meant those terms such as "full-cone", "ip-restricted",
"port-restricted" and "symmetric" that seem widely used in voip industry.
( http://www.voip-info.org/wiki-STUN, or
http://en.wikipedia.org/wiki/Symmetric_NAT)

Never mind it. Sounds like P2PSIP no more needs that info.

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Sun, 02 Jul 2006 16:29:00 -0400

> There seems rare "sorts" of NATs behind which a node can act as SN w/o

But unless the system knows beforehand, it can't use this capability,
as it cannot be reliably detected.

Working for unknown subsets of NATs isn't a useful requirement IMO.

Greg

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Sun, 2 Jul 2006 22:56:38 -0400

> Working for unknown subsets of NATs isn't a useful requirement IMO.

My experience has been that most of the current cheaper home-model
NATs tend to be this desireable type (independent mapping, independent
filtering), so I wouldn't say they're rare.  But they might be behind
an ISP's firewall or the actual node might be running iptables, so
things can be a lot more complex, but it certainly isn't an unusual
case to find a node behind a NAT that can participate fully in an
overlay.

I don't think we need to worry about resolving this right now.  There
are ways that nodes behind NATs can participate fully in an overlay,
and some systems may wish to figure out which can do so, others with
central servers wouldn't.  Figuring that out is an issue for those
deploying a system, not for those of us trying to work out a protocol.

Bruce

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Sun, 02 Jul 2006 23:01:10 -0400

Hi Bruce,

Bruce Lowekamp wrote:
[cut]
> deploying a system, not for those of us trying to work out a protocol.

On this I agree, let's not spend time trying to work out the protocol
details of such a system.  We've probably got ways for devices behind
NATs to get access to P2P services, through Super Peers and STUN Relays
(TURN).

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 3 Jul 2006 08:23:58 -0700

> Working for unknown subsets of NATs isn't a useful requirement IMO.

Capability detection of NAT (or more appropriate to say, of node) seems a
well-known technology for many years. Or, nothing would be worth $ billions.

I don't mind at all any newer definition of the technology, just as I cannot
forbid the sky from raining or my mother from remarrying :)

Peter

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 3 Jul 2006 09:26:56 -0700

> I don't think we need to worry about resolving this right now.

When can this start to be worried?

> There are ways that nodes behind NATs can participate fully in an overlay,

Will ways other than "direct p2p link" jeopardize the initiative of
"P2P"SIP?

> central servers wouldn't.

Do these "others with central server" fall into P2PSIP category? (why they
P2P SIP w/o P2P?)

> Figuring that out is an issue for those

Is "a" protocol enough? It sounds SO SIMPLE :)

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 03 Jul 2006 16:06:20 -0400

Dear Peter.

> well-known technology for many years. Or, nothing would be worth $ billions.

The issue isn't about new devices.
If new devices are deployed, they can be IPv6 capable, or UPNP.

It's about writing protocols that work with legacy services which
cannot be upgraded.

The existing NAT Detection in RFC3489 is deprecated in the draft
precisely because the unreliability of the detection decreases
its worth.

> forbid the sky from raining or my mother from remarrying :)

I hope that you get your wish in both cases anyway.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 3 Jul 2006 14:08:25 -0700

> If new devices are deployed, they can be IPv6 capable, or UPNP.

Wow.... Regardless of new/old devices, I would rather count on you than on
the better-looking IPv6 or uPnP |o|.

> precisely because the unreliability of the detection decreases

NMW, RFC3489 should be deprecated here since it cannot fit P2P well, IMU.

> I hope that you get your wish in both cases anyway.

Your blessings is too late for the *blessed* communist (Chairman Mao of
China) who expressed the two wishes in his sparkling sayings after his dear
comrade had fled for Russia  : -(O)

Peter