Subject: Re: [tram] STUNBIS: Happy STUNballs

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 31 Mar 2017 04:58:08 -0500

Hi Olle,

On 07/26/2016 02:11 AM, Olle E. Johansson wrote:
> Hi!
> 
> STUN now supports IPv6 too (because of the ICE usage) which is a
> significant change. The text in the intro needs to reflect this STUN
> usage and change too. From a previous NAT discovery role it’s about
> network path discovery now.

STUN is supporting IPv6 since RFC 5389, so we do not think that much changed there and we left the text in the introduction as it was.

> 
> A STUN usage use DNS SRV to discover STUN servers. What happens if
> the server name resolves into both A and AAAA addresses? In this
> case, STUNbis needs to have some advice on how to connect. RFC 2782
> just says all IP addresses needs to be tried before moving to the
> next SRV priority, but nothing about order or if we’re connecting in
> parallell or in serial mode. Serial mode would be bad in STUN due to
> the timeouts.
> 
> This needs to be handled in StunBis.
> 

We updated the text to follow the advices in RFC 6555.  That was done in 3 places:

- Section 8, to explain what to do after processing according to RFC 2782 and on a domain name.
- Section 12, to explain what to do with the NAT Discovery Usage.
- Section 13, updating the list of things that other STUN Usage should do, in that case explain what to do with IPv6 and IPv4 addresses.

We'll leave it to icebis and turnbis to do the same for their respective STUN Usages.

Thanks.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 31 Mar 2017 12:12:17 +0200

> On 31 Mar 2017, at 11:58, Marc Petit-Huguenin <[email-masked]> wrote:
> 
> Hi Olle,
> 

Elegant. You are not solving the problem but tell the authors of STUN usages to solve the problem :-)

Note that RFC 6555 has a focus on connection-oriented transports and pretty much leaves old UDP in the cold.
"The mechanism described in this document is directly applicable to
   connection-oriented transports (e.g., TCP, SCTP), which is the scope
   of this document. “

It continues with: "For connectionless transport protocols (e.g.,
   UDP), a similar mechanism can be used if the application has request/
   response semantics (e.g., as done by Interactive Connectivity
   Establishment (ICE) to select a working IPv6 or IPv4 media path
   [RFC6157])."

Which may mean that STUN/UDP is covered.

/O