Subject: [BEHAVE] [Technical Errata Reported] RFC5780 (2939)

From: RFC Errata System <[email-masked]>
Date: Wed, 17 Aug 2011 12:42:23 -0700 (PDT)

The following errata report has been submitted for RFC5780,
"NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939

--------------------------------------
Type: Technical
Reported by: John Selbie <[email-masked]>

Section: 9.1

Original Text
-------------
Section 9.1
   ...
   0x802c: OTHER-ADDRESS

Corrected Text
--------------

Notes
-----
Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489).

But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being 0x802c.

Suggestion: Either update section 7.4 to not reference RFC 3489 or update the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5780 (draft-ietf-behave-nat-behavior-discovery-08)
--------------------------------------
Title               : NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
Publication Date    : May 2010
Author(s)           : D. MacDonald, B. Lowekamp
Category            : EXPERIMENTAL
Source              : Behavior Engineering for Hindrance Avoidance
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 17 Aug 2011 15:26:15 -0700

There _could_ be some case where RFC5780 needs to use OTHER-ADDRESS for
OTHER-ADDRESS's intended purpose.

We have a lot of space for STUN Attributes, so safest thing, I think, is
declaring the text that says 

  "OTHER-ADDRESS uses the same attribute
   number as CHANGED-ADDRESS from RFC 3489".

as the error.

Thoughts?

-d

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: Wednesday, August 17, 2011 12:42 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC5780 (2939)
> 
> 
> Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute
> number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc
> 3489).
> 
> 
> 
> Suggestion: Either update section 7.4 to not reference RFC 3489 or
> update the STUN attribute registry such that OTHER-ADDRESS remains at
> 0x0005.
> 
> Instructions:
> -------------

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 18 Aug 2011 00:32:55 -0400

Wow, this one really surprises me.  We made that change in the -02
draft and somehow missed that paragraph the entire time after.

Looking back on my slides from the change, I believe the paragraph in 7.4:

   OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
   RFC 3489 [RFC3489] because it is simply a new name with the same
   semantics as CHANGED-ADDRESS.  It has been renamed to more clearly
   indicate its function.

should be deleted in its entirety.  It was deliberately renumbered to
break compatibility with 3489 clients.

Bruce

---

From: John Selbie <[email-masked]>
Date: Tue, 23 Aug 2011 11:16:08 -0700

Could a STUN server could be selective about using either based on the
client request type?  If the client request is missing the stun magic
cookie, then it could be assumed to be written to rfc 3489.  As such the
server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send back
OTHER-ADDRESS if the client request contains the stun magic cookie.  Or just
send both?  Would that be permissible?

Can you elaborate on why it was "deliberately renumbered to break
compatibility with 3489" ?  As I read the behavior for handling
"change-request" and calculating the "other address" as described in both
3489 (section 8.1) and 5780 (section 6.1) the text appear to be near
identical in description.  That is, the stun response always contains an
attribute containing the other IP and other port opposite from which the
request arrived on?  Yes?  Or is there some subtle difference I'm missing?

Is there an email exchange discussion for STUN, TURN, and NAT traversal?

jrs

On Wed, Aug 17, 2011 at 9:32 PM, Bruce Lowekamp <[email-masked]> wrote:

> number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489).
> >
> > Suggestion: Either update section 7.4 to not reference RFC 3489 or update
> the STUN attribute registry such that OTHER-ADDRESS remains at 0x0005.
> >
> > Instructions:
> > -------------

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Aug 2011 13:37:43 -0400

On 2011-08-23 14:16, John Selbie wrote:
> server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send
> back OTHER-ADDRESS if the client request contains the stun magic
> cookie.  Or just send both?  Would that be permissible?

I sure hope so. We use that method in Numb (URL in sig) to decide
whether we should reply to a Binding request with a MAPPED-ADDRESS or a
XOR-MAPPED-ADDRESS parameter.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 27 Aug 2011 17:15:02 -0400

> send both?  Would that be permissible?

Yes, one intention was that if you wanted to, you could distinguish
between the two protocols using the magic cookie.

> request arrived on?  Yes?  Or is there some subtle difference I'm missing?

The desire to break compatibility had more to do with the intended
(and described) uses of 3489 than with this actual aspect of the
protocol.  The intention was to ensure that applications written with
3489's characterization approach hard-coded be updated to reflect how
to use ICE, etc for NAT traversal, even if they applied some of the
same techniques that are now in 5780 for appropriate reasons.

> Is there an email exchange discussion for STUN, TURN, and NAT traversal?

STUN and TURN came from behave, so I guess it's still good to discuss them here.

Bruce