Subject: [p2p-sip] STUN (rfc3489)

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 10:29:51 -0700

I found this in draft-ietf-behave-rfc3489bis-03

16.  Changes Since RFC 3489

   This specification updates RFC3489 [13].  This specification differs
   from RFC3489 in the following ways:

   o  Removed the usage of STUN for NAT type detection and binding
      lifetime discovery.  

Here comes another question: 
  Does P2PSIP need to know NAT type of a node before the node is classified as a peer (SN) or client (ON)?

Peter
----- Original Message ----- 
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "Cullen Jennings" <fluffy at cisco.com>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Monday, June 12, 2006 10:24 AM
Subject: Re: [p2p-sip] STUN (rfc3489)

> Sorry. I should have asked:
> 
> 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?
> 
> Peter
> ----- Original Message -----
> From: "Peter Pan" <huang-ming.pan at comcast.net>
> To: "Cullen Jennings" <fluffy at cisco.com>
> Cc: <p2p-sip at cs.columbia.edu>
> Sent: Monday, June 12, 2006 10:19 AM
> Subject: Re: [p2p-sip] STUN (rfc3489)
> 
> 
> > Is it possible to realize a STUN sever defined by
> > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP?
> >
> > Peter
> > ----- Original Message -----
> > From: "Cullen Jennings" <fluffy at cisco.com>
> > To: "Peter Pan" <huang-ming.pan at comcast.net>
> > Cc: <p2p-sip at cs.columbia.edu>
> > Sent: Monday, June 12, 2006 10:10 AM
> > Subject: Re: [p2p-sip] STUN (rfc3489)
> >
> >
> > >
> > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote:
> > >
> > > > Is RFC 3489 based on assumption that STUN server is at least "dual-
> > > > homed".
> > >
> > > no but it is based on the idea that the stun server has two IP
> > > address - it is recommended that these are both on the same
> > > interface. However this changes in the update to it - draft-ietf-
> > > behave-rfc3489bis-03 does not require two IP addresses.
> >
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/05fc7939/attachment.html

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 12 Jun 2006 15:33:13 -0400

My understanding is that part of 3489 was removed because many NATs
are inconsistent---if you make decisions based on a one-time NAT type
discovery as in 3489, that information might not be valid for other
addresses or for some time in the future.

I suspect the right way to decide on node classification is to try to
establish connections with a number of peers.  You can observe whether
you are needing to perform port opening (behind a filter) or relaying
(behind a very ugly NAT) and make your decision based on that.  Of
course, it might still change, but at least you've observed the
property you want to observe with the nodes you care about, rather
than basing an entire decision on an interaction with a  single STUN
server.  Later on, if the node is relaying too much, that decision
might need to be revisited.

If we need to solve the classification problem with 3489bis, there are
solutions.

Bruce

On 6/12/06, Peter Pan <huang-ming.pan at comcast.net> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 13:19:28 -0700

Sounds quite complicated.

By "try to establish connections with a number of 'peers' ", do you mean
that a P2PSIP node can never determine its exact NAT type and must keep (by
continuous attempts) hooking to DHT overlay without "precise" knowledge of
its NAT type? If yes, would that inject series of avalanches of false
(unreachable) node information into overlay?

Peter
----- Original Message -----
From: "Bruce Lowekamp" <lowekamp at cs.wm.edu>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Cullen Jennings" <fluffy at cisco.com>; <p2p-sip at cs.columbia.edu>
Sent: Monday, June 12, 2006 12:33 PM
Subject: Re: [p2p-sip] STUN (rfc3489)

> > Does P2PSIP need to know NAT type of a node before the node is
classified as
> > a peer (SN) or client (ON)?
> >
> >
> > Peter
> >

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 12 Jun 2006 16:32:14 -0400

Yeah, I think it is complicated.  I think it's a true statement,
though, that a node can never be sure it knows its exact NAT type.  Of
course, 99% of the time the situation probably won't be that
complicated and determining the exact situation is fairly simple.

As long as you have relays, though, a node is never unreachable.  It's
just too much of an effort to get to it for it to be practical to use.
 Such a node, if it accidentally gets in on the belief that it is
easier to reach, can be gracefully taken out of the overlay without
causing any errors.

Fortunately, a lot of the use-cases don't require this complex of a
setup, either.

Bruce

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 12 Jun 2006 14:10:20 -0700

Well, it sounds now like a tradeoff between a simple protocol (without the
complexity) for 99% of real-world nodes and a complex protocol that takes
the remaining 1% "rare nodes" into account.

Peter