Subject: Re: [tram] SSODA in TURN-bis

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Jan 2015 05:08:49 +0000

ADDRESS-ERROR-CODE seems useful, client can determine if it’s a temporary or long-term error.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Saturday, January 10, 2015 2:19 AM
To: Oleg Moskalenko
Cc: Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

OK, so we have clear evidence that some deployed servers will fail (deterministically, fortunately) on the current SSODA proposal.

So we're back to which backwards-compatible option we want to pursue. I suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY.

Separately, we need to decide whether we want to pursue issue #2 that I identified previously, i.e., allowing specific error codes to be returned for each address family.

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
I double-checked that with a real test. I ran the coTurn test client (that implements experimental SSODA draft with two RAF attributes) against rfc5766-turn-server and the server yielded error 400 with the message "Only one address family attribute can be used in a request"

:(
As I said, I can eliminate that problem in the subsequent rfc5766-turn-server maintenance releases, but still...
I am sorry that I did not discover that previously and that I advocated an incompatible implementation option.
So, if the WG insists on a backward-compatible protocol in all senses, then we have to choose another option.
Thanks
Oleg

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
I checked the code of rfc5766-turn-server again, and I found that it will NOT handle the multiple-RAF case. It will return 400 error with the message "Only one address family attribute can be used in a request". At least, it's been that way in the 2014 releases. I did not check the older releases.
Sorry that I provided a wrong information about the implementation, before.
I can fix that code but still there are people out there who will be using the "wrong" versions.
So, if we do have to be absolutely backward compatible then we have to use a different option...
Oleg

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
I reviewed the code for restund, reTurn, and rfc5766-turn-server and they all appear to handle RAF (and multiple RAF) OK.

The problem, as I see it, is that there may be other TURN servers, perhaps non-open-source ones, that work fine today with Chrome, but will start returning errors when we include RAF or multiple RAF, and so making this change may break some small number of apps (who will then blame Chrome). We just don't know what is out there.

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
After your detail analysis and the sentence “For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited.”, I think it may be better to keep only one attribute to fulfill the SSODA requirement?

There is no requirement that SSODA functionality be realized with only one attribute, nor that the protocol be elegant, nor that it exhibits symmetry that is pleasing to the eye.

There *is* a requirement that it be backwards-compatible though. Whether that means compatible with the spec or compatible with actual implementations is a matter of debate.

Justin, if we can't find a single implementation that would barf, why would Chrome have to implement a complex fallback mechanism?

Simon

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 14 Jan 2015 10:50:30 +0000

Hi,

I do not see a problem with a TURN server returning a 400 error code if it gets confused by two RAFs.
This is almost covered in section 2.4 of the SSODA draft. Client fallback to non-SSODA mode when encountering an error seems trivial.
(Unless the TURN server ends up using to much CPU, overheats, and causes a fire in the datacenter)

But I might like c) better anyway. Adding a new attribute seems cleaner when adding new functionality.

.-.
Pål-Erik

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Saturday, January 10, 2015 2:19 AM
To: Oleg Moskalenko
Cc: Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] SSODA in TURN-bis

:(

Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 14 Jan 2015 14:44:02 -0800

On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> This is almost covered in section 2.4 of the SSODA draft. Client fallback
> to non-SSODA mode when encountering an error seems trivial.

Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also a
good thing.

>
>  .-.
> Pål-Erik
>
>  On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <[email-masked]>
> wrote:
>
>   *From:* Justin Uberti [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, January 10, 2015 2:19 AM
> *To:* Oleg Moskalenko
> *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy);
> [email-masked]
> *Subject:* Re: [tram] SSODA in TURN-bis
>
>  OK, so we have clear evidence that some deployed servers will fail
> (deterministically, fortunately) on the current SSODA proposal.
>
>   So we're back to which backwards-compatible option we want to pursue. I
> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY.
>
>   Separately, we need to decide whether we want to pursue issue #2 that I
> identified previously, i.e., allowing specific error codes to be returned
> for each address family.
>
>  On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <[email-masked]>
> wrote:
>
> I double-checked that with a real test. I ran the coTurn test client (that
> implements experimental SSODA draft with two RAF attributes) against
> rfc5766-turn-server and the server yielded error 400 with the message "Only
> one address family attribute can be used in a request"
>
> :(
>
> As I said, I can eliminate that problem in the subsequent
> rfc5766-turn-server maintenance releases, but still...
>
>  On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <[email-masked]>
> wrote:
>
> I checked the code of rfc5766-turn-server again, and I found that it will
> NOT handle the multiple-RAF case. It will return 400 error with the message
> "Only one address family attribute can be used in a request". At least,
> it's been that way in the 2014 releases. I did not check the older releases.
>
>   On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <[email-masked]>
> wrote:
>
>   I reviewed the code for restund, reTurn, and rfc5766-turn-server and
> they all appear to handle RAF (and multiple RAF) OK.
>
>   The problem, as I see it, is that there may be other TURN servers,
> perhaps non-open-source ones, that work fine today with Chrome, but will
> start returning errors when we include RAF or multiple RAF, and so making
> this change may break some small number of apps (who will then blame
> Chrome). We just don't know what is out there.
>
>
>
>  On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <[email-masked]>
> wrote:
>
>  On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <[email-masked]>
> wrote:
>  After your detail analysis and the sentence “For either b/c, we would
> need to say that including both RAF and OAF/AAF for the same address family
> is prohibited.”, I think it may be better to keep only one attribute to
> fulfill the SSODA requirement?
>
> There is no requirement that SSODA functionality be realized with only one
> attribute, nor that the protocol be elegant, nor that it exhibits symmetry
> that is pleasing to the eye.
>
>   There *is* a requirement that it be backwards-compatible though.
> Whether that means compatible with the spec or compatible with actual
> implementations is a matter of debate.
>
>   Justin, if we can't find a single implementation that would barf, why
> would Chrome have to implement a complex fallback mechanism?
>
>   Simon
>
>
>
> [email-masked]
> [email-masked]
> [email-masked]

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 15 Jan 2015 11:19:15 +0000

On 14 Jan 2015, at 23:44, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also a good thing.

Good point. Since this probably would take some time to deploy on the server side the extra chatter could become a bit annoying.

Tiru, do you have enough information to add this to the TURNbis draft? Or do you think more discussion is needed?

.-.
Pål-Erik

.-.
Pål-Erik

-Tiru

:(

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Jan 2015 14:24:04 +0000

From: Pal Martinsen (palmarti)
Sent: Thursday, January 15, 2015 4:49 PM
To: Justin Uberti; Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

Tiru, do you have enough information to add this to the TURNbis draft?

[TR] Yes, If there are no further objections will update the draft next week.

Cheers,
-Tiru

Or do you think more discussion is needed?

.-.
Pål-Erik

.-.
Pål-Erik

-Tiru

:(

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 16 Jan 2015 14:01:51 +0800

Hi,Tiru,Pal and Justin:

I suggest we use the “REQUESTED-ADDRESS-FAMILY” attribute to fulfill the function of SSODA by clarifying the behavior of TURN server based on whether this attribute is present or not:

1. If the “RAF” attribute is not present, then the allocated relay address family will be same as the source address’s family  of Allocate Request message.  https://tools.ietf.org/html/rfc6156#section-4.2 has the following description:

“If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST

   allocate an IPv4-relayed transport address for the TURN client.  If

   allocation of IPv4 addresses is disabled by local policy, the server

   returns a 440 (Address Family not Supported) Allocate error response.”

This paragraph should be modified as below:

“If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST

   allocate an relayed transport address from the same family as the source address of Allocate Request message for the TURN client.  If this

   allocation is disabled by local policy, the server

   returns a 440 (Address Family not Supported) Allocate error response.”

2. If the “RAF” attribute is present, then the following procedure of the client and server should only need to conform to https://tools.ietf.org/html/rfc6156, no new attribute and procedure need be introduced. 

3. Here, the RAF attribute act just as the “Additional Attribute Family” attribute that I proposed previously.  Will such solution be less confusable and be less prone to problem to the TURN developer?

RFC6156 also describes the following sentence:
“The REQUESTED-ADDRESS-FAMILY
   attribute allows a client to explicitly request the address type the
   TURN server will allocate (e.g., an IPv4-only node may request the
   TURN server to allocate an IPv6 address).”

If we can change the name of the attribute, then change the attribute name “REQUESTED-ADDRESS-FAMILY” to “Additional Attribute Family” may be more better. If this is impossible, we just need only update the behavior of TURN server that described in RFC6156,  as I suggested above.

Best Regards.

Aijun Wang

From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, January 15, 2015 10:24 PM
To: Pal Martinsen (palmarti); Justin Uberti
Cc: [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

 

On 14 Jan 2015, at 23:44, Justin Uberti <[email-masked]> wrote:

On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:

Hi, 

Cheers,

-Tiru

.-.

Pål-Erik

.-.

Pål-Erik

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

-Tiru

From: Justin Uberti [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Saturday, January 10, 2015 2:19 AM
To: Oleg Moskalenko
Cc: Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy);  <mailto:[email-masked]> [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko < <mailto:[email-masked]> [email-masked]> wrote:

:(

Thanks
Oleg

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko < <mailto:[email-masked]> [email-masked]> wrote:

Oleg

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti < <mailto:[email-masked]> [email-masked]> wrote:

 

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault < <mailto:[email-masked]> [email-masked]> wrote:

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang < <mailto:[email-masked]> [email-masked]> wrote:

Simon

_______________________________________________
tram mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 15 Jan 2015 22:23:46 -0800

I think that that proposal makes sense. But I am not sure that it is
backward-compatible enough. We have to go through all cases of
SSODA/non-SSODA entities communicating, for different protocol request
options.

Aijun, would you like to go through all those cases to double-check that it
works as supposed ?

Thanks
Oleg

On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <[email-masked]>
wrote:

> Hi,Tiru,Pal and Justin:
>
>
>
> I suggest we use the “REQUESTED-ADDRESS-FAMILY” attribute to fulfill the
> function of SSODA by clarifying the behavior of TURN server based on
> whether this attribute is present or not:
>
>
>
> 1. If the “RAF” attribute is not present, then the allocated relay address
> family will be same as the source address’s family  of Allocate Request
> message.  https://tools.ietf.org/html/rfc6156#section-4.2 has the
> following description:
>
>
>
>    allocate an relayed transport address *from the same family as the
> source address of Allocate Request message* for the TURN client.  If
> *this*
>
> *   allocation* is disabled by local policy, the server
>
> 2. If the “RAF” attribute is present, then the following procedure of the
> client and server should only need to conform to
> https://tools.ietf.org/html/rfc6156, no new attribute and procedure need
> be introduced.
>
>
>
> 3. Here, the RAF attribute act just as the “Additional Attribute Family”
> attribute that I proposed previously.  Will such solution be less
> confusable and be less prone to problem to the TURN developer?
>
>    attribute allows a client to *explicitly* request the address type the
>
> If we can change the name of the attribute, then change the attribute name
> “REQUESTED-ADDRESS-FAMILY” to “Additional Attribute Family” may be more
> better. If this is impossible, we just need only update the behavior of
> TURN server that described in RFC6156,  as I suggested above.
>
>
>
> Best Regards.
>
> Aijun Wang
>
>
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Tirumaleswar
> Reddy (tireddy)
> *Sent:* Thursday, January 15, 2015 10:24 PM
> *To:* Pal Martinsen (palmarti); Justin Uberti
>
> *Cc:* [email-masked]
> *From:* Pal Martinsen (palmarti)
> *Sent:* Thursday, January 15, 2015 4:49 PM
> *To:* Justin Uberti; Tirumaleswar Reddy (tireddy)
> *Cc:* [email-masked]
> Good point. Since this probably would take some time to deploy on the
> server side the extra chatter could become a bit annoying.
>
>
>
> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <[email-masked]> wrote:
>
> I reviewed the code for restund, reTurn, and rfc5766-turn-server and they
> all appear to handle RAF (and multiple RAF) OK.
>
>
>
> The problem, as I see it, is that there may be other TURN servers, perhaps
> non-open-source ones, that work fine today with Chrome, but will start
> returning errors when we include RAF or multiple RAF, and so making this
> change may break some small number of apps (who will then blame Chrome). We
> just don't know what is out there.
>
>
>
>
>
>
>
> After your detail analysis and the sentence “For either b/c, we would need
> to say that including both RAF and OAF/AAF for the same address family is
> prohibited.”, I think it may be better to keep only one attribute to
> There *is* a requirement that it be backwards-compatible though. Whether
> that means compatible with the spec or compatible with actual

---

From: Justin Uberti <[email-masked]>
Date: Fri, 16 Jan 2015 09:10:33 -0800

It's too late to take this approach. Every existing TURN server out there
assumes that no RAF = IPv4. We can't change the past.

It's also not clear how you expect this to provide SSODA functionality,
e.g. how do you distinguish between an IPv4 client asking for v6 only vs
v4+v6.

On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <[email-masked]>
wrote:

> Aijun, would you like to go through all those cases to double-check that
> it works as supposed ?
>
> Thanks
> Oleg
>
>
>> 1. If the “RAF” attribute is not present, then the allocated relay
>> address family will be same as the source address’s family  of Allocate
>> Request message.  https://tools.ietf.org/html/rfc6156#section-4.2 has
>> the following description:
>>
>>
>>
>> If we can change the name of the attribute, then change the attribute
>> name “REQUESTED-ADDRESS-FAMILY” to “Additional Attribute Family” may be
>> more better. If this is impossible, we just need only update the behavior
>> of TURN server that described in RFC6156,  as I suggested above.
>>
>>
>>
>> Best Regards.
>>
>> Aijun Wang
>>
>>
>>
>>
>>
>> I double-checked that with a real test. I ran the coTurn test client
>> (that implements experimental SSODA draft with two RAF attributes) against
>> There is no requirement that SSODA functionality be realized with only
>> one attribute, nor that the protocol be elegant, nor that it exhibits
>> symmetry that is pleasing to the eye.
>>
>>
>>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 16 Jan 2015 10:35:22 -0800

Then we are back to, I guess, the option c).

On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti <[email-masked]> wrote:

>>> 2. If the “RAF” attribute is present, then the following procedure of
>>> the client and server should only need to conform to
>>> https://tools.ietf.org/html/rfc6156, no new attribute and procedure
>>> need be introduced.
>>>
>>>
>>>
>>> This is almost covered in section 2.4 of the SSODA draft. Client
>>> fallback to non-SSODA mode when encountering an error seems trivial.
>>>
>>> I checked the code of rfc5766-turn-server again, and I found that it
>>> will NOT handle the multiple-RAF case. It will return 400 error with the
>>> message "Only one address family attribute can be used in a request". At
>>> least, it's been that way in the 2014 releases. I did not check the older
>>> releases.
>>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 16 Jan 2015 11:36:49 -0800

yeah. I think we should just get this into turn-bis and be done with it.

Nobody seemed to have much of an opinion on ADDRESS-ERROR-CODE, so I
suggest we write it up and see if we still like it.

On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko <[email-masked]>
wrote:

>>>> I suggest we use the “REQUESTED-ADDRESS-FAMILY” attribute to fulfill
>>>> the function of SSODA by clarifying the behavior of TURN server based on
>>>> 3. Here, the RAF attribute act just as the “Additional Attribute
>>>> Family” attribute that I proposed previously.  Will such solution be less
>>>> name “REQUESTED-ADDRESS-FAMILY” to “Additional Attribute Family” may
>>>> be more better. If this is impossible, we just need only update the
>>>> behavior of TURN server that described in RFC6156,  as I suggested above.
>>>>
>>>>
>>>>
>>>> Best Regards.
>>>>
>>>> Aijun Wang
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 19 Jan 2015 17:11:05 +0800

Hi, Justin:

According to the guideline defined in https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with the situation that one IPv6-only client send the Allocation Request, but does not include RAF attribute? Will you still allocate it one IPv4 Relay Address in default?

I think IPv4-only client will always need one IPv4 relay address and IPv6-only client will always need one IPv6 relay address. If they need additional relay address that in belong to other address family, they just need include one RAF or AAF attribute in the Allocate Request, this can accomplish the SSODA requirement that you mentioned.

TURN server that receives the Allocation Request which includes one RAF or AAF attribute should do the following task:

1. Check the validity of the message.  The required RAF or AAF attribute should be different from the address family of source address of the Allocate Request message.

2. If valid, Allocate two relay address for this client simultaneously. One for default address type, and the other is the required address type.

3. All other guidelines of RFC6156 keeps unchanged.

Is this more simple?

Best Regards.

Aijun Wang.

From: Justin Uberti [mailto:[email-masked]] 
Sent: Saturday, January 17, 2015 3:37 AM
To: Oleg Moskalenko
Cc: Aijun Wang; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

Nobody seemed to have much of an opinion on ADDRESS-ERROR-CODE, so I suggest we write it up and see if we still like it.

On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko <[email-masked]> wrote:

It's too late to take this approach. Every existing TURN server out there assumes that no RAF = IPv4. We can't change the past.

It's also not clear how you expect this to provide SSODA functionality, e.g. how do you distinguish between an IPv4 client asking for v6 only vs v4+v6.

On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <[email-masked]> wrote:

I think that that proposal makes sense. But I am not sure that it is backward-compatible enough. We have to go through all cases of SSODA/non-SSODA entities communicating, for different protocol request options.

Aijun, would you like to go through all those cases to double-check that it works as supposed ?

Thanks
Oleg

On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <[email-masked]> wrote:

Hi,Tiru,Pal and Justin:

Best Regards.

Aijun Wang

Cc: [email-masked]

 

 

Hi, 

Cheers,

-Tiru

.-.

Pål-Erik

.-.

Pål-Erik

-Tiru

:(

Thanks
Oleg

Oleg

 

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 19 Jan 2015 01:22:59 -0800

On Mon, Jan 19, 2015 at 1:11 AM, Aijun Wang <[email-masked]>
wrote:

> Hi, Justin:
>
>
>
> According to the guideline defined in
> https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with the
> situation that one IPv6-only client send the Allocation Request, but does
> not include RAF attribute? Will you still allocate it one IPv4 Relay
> Address in default?
>

The section text is saying:

If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST
allocate an IPv4-relayed transport address for the TURN client.

 The existing RFC6156-compliant servers behave that way.

>
> I think IPv4-only client will always need one IPv4 relay address and
> IPv6-only client will always need one IPv6 relay address. If they need
> additional relay address that in belong to other address family, they just
> need include one RAF or AAF attribute in the Allocate Request, this can
> accomplish the SSODA requirement that you mentioned.
>
>
>
> TURN server that receives the Allocation Request which includes one RAF or
> AAF attribute should do the following task:
>
> 1. Check the validity of the message.  The required RAF or AAF attribute
> should be different from the address family of source address of the
> Allocate Request message.
>

According to RFC 6156, if an IPv6 client needs an IPv6 relay, then it
includes IPv6 RAF in the request. Some clients will continue behaving that
way.

> 2. If valid, Allocate two relay address for this client simultaneously.
> One for default address type, and the other is the required address type.
>

As I said before, I like your proposal, but it is incompatible with the old
clients and with the old servers, as far as I can see. We have a legacy of
RFC 6156 that makes SSODA rather complicated.

Oleg

>
>
> Best Regards.
>
> Aijun Wang.
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Saturday, January 17, 2015 3:37 AM
> *To:* Oleg Moskalenko
> *Cc:* Aijun Wang; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti);
> [email-masked]
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 Jan 2015 17:33:32 -0800

On Mon, Jan 19, 2015 at 1:22 AM, Oleg Moskalenko <[email-masked]>
wrote:

>> https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with
>> the situation that one IPv6-only client send the Allocation Request, but
>> does not include RAF attribute? Will you still allocate it one IPv4 Relay
>> Address in default?
>>
>
>> TURN server that receives the Allocation Request which includes one RAF
>> or AAF attribute should do the following task:
>>
> As I said before, I like your proposal, but it is incompatible with the
> old clients and with the old servers, as far as I can see. We have a legacy
> of RFC 6156 that makes SSODA rather complicated.
>

We can't change the past, we can only work around it.