Subject: [tram] IPv4 and IPv6 allocations

From: Mallinath Bareddy <[email-masked]>
Date: Wed, 19 Feb 2014 07:31:44 -0800

Hi All,

>From RFC 5766,
     Both the server and client keep track of a value known as the

   5-TUPLE.  At the client, the 5-tuple consists of the client's host
   transport address, the server transport address, and the transport
   protocol used by the client to communicate with the server.  At the
   server, the 5-tuple value is the same except that the client's host
   transport address is replaced by the client's server-reflexive
   address, since that is the client's address as seen by the server.

I have a scenario where Turn client is sending IPv4 and a IPv6 (using
REQUESTED-ADDRESS-FAMILY attribute) allocation requests from the same
host transport address. The reason to send IPv6 allocation request is
to connect to a IPv6 only client.

>From above definition both allocation requests will result in same
5-tuple at the server. How does TURN server demux requests from
client, leading to the proper allocation object?

Regards,

Mallinath

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 10:42:02 -0500

Le 2014-02-19 10:31, Mallinath Bareddy a écrit :
> I have a scenario where Turn client is sending IPv4 and a IPv6 (using REQUESTED-ADDRESS-FAMILY attribute) allocation requests from the same host transport address. The reason to send IPv6 allocation request is to connect to a IPv6 only client.
> 
> 
> 
> From above definition both allocation requests will result in same 5-tuple at the server.

No. There can be only one allocation per 5-tuple.

> How does TURN server demux requests from client, leading to the proper allocation object?

Have the client use a different source port.

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: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Feb 2014 16:37:59 +0000

> Have the client use a different source port.

IMHO this would make a good optimisation. Endpoints can discover how to reach the TURN server well before a call is made, webRTC is a bit more tricky but Ill guess there are room for some sort of “pre call” discovery there as well. The agent can thus lock down to a specific IP address family talking to the TURN server. To further reduce chatter it would be nice to be able to allocate two types of IP  RELAY addresses with one allocation message. Writing up draft describing that would not be to hard unless I miss something.

.-.
Pål-Erik

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 11:44:16 -0500

Le 2014-02-19 11:37, Pal Martinsen (palmarti) a écrit :
> IMHO this would make a good optimisation. Endpoints can discover how
> to reach the TURN server well before a call is made, webRTC is a bit
> more tricky but Ill guess there are room for some sort of “pre call”
> discovery there as well. The agent can thus lock down to a specific
> IP address family talking to the TURN server. To further reduce
> chatter it would be nice to be able to allocate two types of IP
> RELAY addresses with one allocation message. Writing up draft
> describing that would not be to hard unless I miss something.

I think it would be super hard, as in it would require completely
redesigning TURN. :)

All the TURN messages rely on there being a single allocation per
5-tuple. For example, in a Send indication, you don't tell the server
out of which allocation (i.e., external port) to send the actual packet.
So you would need to add an "allocation ID" attribute to just about
everything: Send, Data, Refresh, etc. Then we need to think about
channels. By this point we are fairly discouraged, and we still need to
think about TURN-TCP. Yuck.

One allocation per 5-tuple. I don't think we're changing this anytime soon.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 08:49:19 -0800

If we allow two allocations per session that would be unnecessary
complication that does not serve any immediate purpose that cannot be
served in another way and it would encourage waste of resources. I do not
think that would be a good idea.

Oleg

On Wed, Feb 19, 2014 at 8:44 AM, Simon Perreault <
[email-masked]> wrote:

> > more tricky but Ill guess there are room for some sort of "pre call"

---

From: Mallinath Bareddy <[email-masked]>
Date: Wed, 19 Feb 2014 09:07:42 -0800

Pal, I am not sure how a "pre call" setup will help in this case, as we
will not know ahead of time about the peer address type. It's not just
reaching the TURN server.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Feb 2014 17:09:05 +0000

> I think it would be super hard, as in it would require completely
Wouldn't that be fun.. ;-)

> think about TURN-TCP. Yuck.
We are only talking about allocating _one_ IPv4 and _one_ IPv6 address in the same allocation message.
So the ip addr type of the peer_addr in the send indication message would make it clear from where the TURN server should send the packet. Likewise the agent would know the incoming packet arrived at the TURN server by looking at the peer addr in the data indication message. 

When it comes to binding a channel this is normally done after ICE is finished and the client decides to use the TURN server.  We can then discard  one of the allocated IP addresses to simplify. 

Still got the feeling I miss something though..

> One allocation per 5-tuple. I don't think we're changing this anytime soon.

Currently some of our endpoints have 6 media lines, 1x Audio, 2x Video, 1xFECC, 1xBFCP and 1xIX(app). Since 4 of those use RTP and RTCP this gives us 10 TURN allocations pr call. 20 if we want to suport IPv4/IPv6 dual stack via TURN. Our windows soft client ran into some problems regarding the number of socket one process could open. 

It would reduce some pain for us, but it is dependant of how simple this would be to implement on the TURN server side.

.-.
Pål-Erik

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 12:12:47 -0500

> So the ip addr type of the peer_addr in the send indication message would make it clear from where the TURN server should send the packet. Likewise the agent would know the incoming packet arrived…

You're right!

> When it comes to binding a channel this is normally done after ICE is finished and the client decides to use the TURN server.  We can then discard  one of the allocated IP addresses to simplify. 

Sounds good.

> Currently some of our endpoints have 6 media lines, 1x Audio, 2x Video, 1xFECC, 1xBFCP and 1xIX(app). Since 4 of those use RTP and RTCP this gives us 10 TURN allocations pr call. 20 if we want to s…

!!!

> It would reduce some pain for us, but it is dependant of how simple this would be to implement on the TURN server side.

In my experience: very easy.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 12:16:16 -0500

Le 2014-02-19 12:07, Mallinath Bareddy a écrit :
> will not know ahead of time about the peer address type.

You don't need to know the peer's address type (with ICE, does such a
concept exist anyway?). To properly support dual stack, you need to
unconditionally create IPv4 and IPv6 relayed candidates.

>From RFC 6157:

   When following the ICE procedures, in addition to local addresses,
   user agents may need to obtain addresses from relays; for example, an
   IPv6 user agent would obtain an IPv4 address from a relay.  The relay
   would forward the traffic received on this IPv4 address to the user
   agent using IPv6.  Such user agents MAY use any mechanism to obtain
   addresses in relays, but, following the recommendations in ICE, it is
   RECOMMENDED that user agents support STUN relay usage [6] [8] for
   this purpose.

   IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
   using the ICE procedures to generate all their offers.  This way,
   both IPv4-only and IPv6-only answerers will be able to generate a
   mutually acceptable answer that establishes a session (having used
   ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
   session establishment time because all answerers will find the offer
   valid.)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 12:28:14 -0500

Here's a crazy idea: why not have servers unconditionally create an IPv4
*and* an IPv6 allocation on any Allocate request? No need for a new
parameter. What could go wrong? After all, we want clients to support
dual-stack. This could actually help clients do it "by default" without
having to create multiple TURN sessions.

Simon

---

From: "Yoakum, John H (John)" <[email-masked]>
Date: Wed, 19 Feb 2014 17:46:59 +0000

+1
I love out of the box thinking!  Not sure what could go wrong but worth thinking about.  Also it might be interesting to explore if there is any role for IPv6 temporary addresses in relation to media flows.

Cheers,
John

AVAYA
1.919.425.8446 

-----Original Message-----
From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Wednesday, February 19, 2014 12:28 PM
To: [email-masked]
Subject: Re: [tram] IPv4 and IPv6 allocations

Here's a crazy idea: why not have servers unconditionally create an IPv4
*and* an IPv6 allocation on any Allocate request? No need for a new parameter. What could go wrong? After all, we want clients to support dual-stack. This could actually help clients do it "by default" without having to create multiple TURN sessions.

Simon

---

From: Mallinath Bareddy <[email-masked]>
Date: Wed, 19 Feb 2014 10:04:29 -0800

+1

On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) <[email-masked]>wrote:

> +1
> I love out of the box thinking!  Not sure what could go wrong but worth
> thinking about.  Also it might be interesting to explore if there is any
> role for IPv6 temporary addresses in relation to media flows.
>
>
> Cheers,
> John
>
> AVAYA
> 1.919.425.8446
>
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Feb 2014 19:58:50 +0000

-1 ;-)

Reading RFC5766 they use language that indicates that you will only receive one XOR-RELAYED-ADDRESS attribute. An old client that receives two might pick the wrong one, and get confused since he asked for a IPv4 address and got a IPv6 address. There is no way for the client to get out of that situation. (Furiously checking my own TURN client implementation…)

I would like to TURN (*sigh) around..

I think it would be better for the client to include two REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead. If the server supports that everything is fine. If the TURN server responds with only one RELAY address, the client would notice and could easily request the other address family on a different 5-tuple. Same goes if the TURN server return an error, the client can go back to old behaviour.

The client could do some of those checks prior to all setup and would know what the TURN server supports. But that is an implementation detail.

.-.
Pål-Erik

On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy <[email-masked]<mailto:[email-masked]>> wrote:

+1

On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) <[email-masked]<mailto:[email-masked]>> wrote:
+1
I love out of the box thinking!  Not sure what could go wrong but worth thinking about.  Also it might be interesting to explore if there is any role for IPv6 temporary addresses in relation to media flows.

Cheers,
John

AVAYA
1.919.425.8446<tel:1.919.425.8446>

-----Original Message-----
From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Perreault
Sent: Wednesday, February 19, 2014 12:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] IPv4 and IPv6 allocations

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

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

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

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 12:02:00 -0800

I'd leave it to the future possible TURN-bis standard. I'd suggest NOT to
tweak the existing TURN servers which follow RFC 5766 procedure. In the
TURN-bis, we can vent it properly.

On Wed, Feb 19, 2014 at 11:58 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>  -1 ;-)
>
>  Reading RFC5766 they use language that indicates that you will only
> receive one XOR-RELAYED-ADDRESS attribute. An old client that receives two
> might pick the wrong one, and get confused since he asked for a IPv4
> address and got a IPv6 address. There is no way for the client to get out
> of that situation. (Furiously checking my own TURN client implementation...)
>
>  I think it would be better for the client to include two
> REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead. If
> the server supports that everything is fine. If the TURN server responds
> with only one RELAY address, the client would notice and could easily
> request the other address family on a different 5-tuple. Same goes if the
> TURN server return an error, the client can go back to old behaviour.
>
>  The client could do some of those checks prior to all setup and would
> know what the TURN server supports. But that is an implementation detail.
>
>  .-.
> Pål-Erik
>
>
>  On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy <[email-masked]>
> wrote:
>
>  +1
>
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 15:06:20 -0500

Le 2014-02-19 14:58, Pal Martinsen (palmarti) a écrit :
> receive one XOR-RELAYED-ADDRESS attribute. An old client that receives
> two might pick the wrong one, and get confused since he asked for a IPv4
> address and got a IPv6 address. There is no way for the client to get
> out of that situation. (Furiously checking my own TURN client
> implementation…)

Backwards compatibility is why we can't have nice things... ;)

How about we specify which XOR-RELAYED-ADDRESS parameter goes first? We
can expect older clients to only look at the first one. So if you don't
include REQUESTED-ADDRESS-FAMILY, the server returns both IPv4 and IPv6,
and puts IPv4 first. If you do include REQUESTED-ADDRESS-FAMILY, the
server still allocates two, the requested family is first in the
response. If that works with existing clients (and it would be easy to
try those we know), then we can have our cake and it it too!

> REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead.
> If the server supports that everything is fine. If the TURN server
> responds with only one RELAY address, the client would notice and could
> easily request the other address family on a different 5-tuple. Same
> goes if the TURN server return an error, the client can go back to old
> behaviour. 

That's a fine workaround.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 12:18:22 -0800

If the client explicitly requested an ip family - why the server must waste resources and allocated a useless (possibly) socket of a different family ?

The server resources must be taken into account, too.

Sent from my iPhone

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 15:27:59 -0500

> If the client explicitly requested an ip family - why the server must waste resources and allocated a useless (possibly) socket of a different family ?

Right. So:

No REQUESTED-ADDRESS-FAMILY: allocate both, IPv4 goes first
REQUESTED-ADDRESS-FAMILY = IPv4: allocate only IPv4
REQUESTED-ADDRESS-FAMILY = IPv6: allocate only IPv6
REQUESTED-ADDRESS-FAMILY = IPv4+IPv6: allocate both, order doesn't matter

> The server resources must be taken into account, too.

Right. And single-stack servers too. And local security policy.

But seriously, just provision your TURN server with a /96 and let it go
wild. :)

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 12:45:21 -0800

I d suggest to allocate both families ONLY when ipv4+ipv6 are used in the requests, then it will 100% compatible and non-resource-wasting.

Sent from my iPhone

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Feb 2014 18:38:57 -0800

OK. So to do this we make the following changes:
Allocate: add support for request of v4+v6 requested-address, allow return
of v4 + v6 relayed address
Refresh: None needed? Or do we want to allow client to pick the address to
refresh via requested-address-family
CreatePermission: Binding to create permission on implicit through
destination address type
ChannelData: same as CreatePermission

This SGTM, as it allows a single socket to create local, stun, relay v4,
and relay v6 candidates with no major TURN changes.

On Wed, Feb 19, 2014 at 12:45 PM, Oleg Moskalenko <[email-masked]>wrote:

> I d suggest to allocate both families ONLY when ipv4+ipv6 are used in the
> requests, then it will 100% compatible and non-resource-wasting.
>
> Sent from my iPhone
>
> >> If the client explicitly requested an ip family - why the server must
> waste resources and allocated a useless (possibly) socket of a different
> family ?
> >
> > Right. So:
> >

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 22:49:33 -0800

Justin, please see below:

On Wed, Feb 19, 2014 at 6:38 PM, Justin Uberti <[email-masked]> wrote:

> Refresh: None needed?
Or do we want to allow client to pick the address to refresh via
> requested-address-family

If we are going to make it backward compatible, then we must refresh with
explicit address-family in the refresh request. Only relay endpoints which
families are set in the refresh request will be refreshed. Then the old
specs will be a subset of the new specs.

> CreatePermission: Binding to create permission on implicit through

I agree

> ChannelData: same as CreatePermission

I agree

> and relay v6 candidates with no major TURN changes.
I agree

Oleg

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Feb 2014 22:52:32 -0800

On Wed, Feb 19, 2014 at 10:49 PM, Oleg Moskalenko <[email-masked]>wrote:

>> Allocate: add support for request of v4+v6 requested-address, allow
>> return of v4 + v6 relayed address
>> Refresh: None needed?
>>
>>

I don't follow. Only new clients will allocate v4+v6 on the same socket.
(And the existing spec says to NOT use r-a-f in the refresh request.)

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 19 Feb 2014 23:15:11 -0800

> I don't follow. Only new clients will allocate v4+v6 on the same socket.

That's true.

> (And the existing spec says to NOT use r-a-f in the refresh request.)
That is somewhat a grey area... this is what RFC 6156 is saying:

========================================================================

5.1 <http://tools.ietf.org/search/rfc6156#section-5.1>.  Sending a
Refresh Request

   To perform an allocation refresh, the client generates a Refresh
   Request as described in Section 7.1 of [RFC5766]
<http://tools.ietf.org/search/rfc5766#section-7.1>.  The client MUST
   NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh
   Request.
5.2 <http://tools.ietf.org/search/rfc6156#section-5.2>.  Receiving a
Refresh Request

   If a server receives a Refresh Request with a REQUESTED-ADDRESS-
   FAMILY attribute, and the attribute's value doesn't match the address
   family of the allocation, the server MUST reply with a 443 (Peer
   Address Family Mismatch) Refresh error response.

==============================================

So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may
expect that attribute...

So, I reconsider my opinion: let's not use the address-family in the
REFRESH at all, and refresh all relay endpoints regardless of their
protocols.

Regards,
Oleg

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 20 Feb 2014 11:50:05 +0000

On 20 Feb 2014, at 08:15 am, Oleg Moskalenko <[email-masked]> wrote:
[cut]
> 
> 
> So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may expect that attribute...
> 
I just noticed that as well. Funny..

> So, I reconsider my opinion: let's not use the address-family in the REFRESH at all, and refresh all relay endpoints regardless of their protocols.
> 
Well it is nice to have in there as the refresh is also used to delete an allocation. So if you after ICE is completed ends up only using the IPv6 allocation you can delete the IPv4 allocation. This frees up resources on the TURN server. 

.-.
Pål-Erik

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 09:25:27 -0800

On Thu, Feb 20, 2014 at 3:50 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> Well it is nice to have in there as the refresh is also used to delete an
> allocation. So if you after ICE is completed ends up only using the IPv6
> allocation you can delete the IPv4 allocation. This frees up resources on
> the TURN server.
>

Yeah, that was my thinking as well. If RAF is absent, the refresh applies
to all allocations. If the RAF is specified, the specific allocations are
refreshed/deleted, or an error if the RAF doesn't match the existing
allocations.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Feb 2014 09:39:23 -0800

> refreshed/deleted, or an error if the RAF doesn't match the existing

I suppose that this is probably the "least intrusive" option - if we want
to be able to free the resources. But I'd like to clarify the terminology.
How many allocations we have per TURN session ? I'd suggest to use the term
"relay endpoints" for the allocated relay sockets but I'd keep term
"allocation" as a synonym to "TURN session" (and then we have a single
allocation even if we have two relay endpoints per allocation).

Or we can separate "TURN session" and "allocation" and make the
"allocation" a synonym to "relay endpoint". We have to agree on a single
terminology to avoid the confusions.

So, RAF in REFRESH can be:

1) absent - then it is applicable to all available relay endpoints in the
session;
2) ipv4 - then it is applicable to ipv4 endpoint only and returns 443 if
ipv4 endpoint does not exist;
3) ipv6 - then it is applicable to ipv6 endpoint only and returns 443 if
ipv6 endpoint does not exist;
4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443
if ipv4 OR ipv6 endpoint does not exist;

Honestly, I'd remove 443 requirement and if the endpoint does not exist I'd
just ignore the request. That would simplify the client code on resource
cleaning. But that would make the specs not-backward-compatible so I
suggest keeping the 443 error.

Oleg

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 09:41:50 -0800

On Thu, Feb 20, 2014 at 9:39 AM, Oleg Moskalenko <[email-masked]>wrote:

>>> Well it is nice to have in there as the refresh is also used to delete
>>> an allocation. So if you after ICE is completed ends up only using the IPv6
> Honestly, I'd remove 443 requirement and if the endpoint does not exist
> I'd just ignore the request. That would simplify the client code on
> resource cleaning. But that would make the specs not-backward-compatible so
> I suggest keeping the 443 error.
>
>
I think it would be good for the client to know that its REFRESH request
could not be fully handled by the server. Ergo, let's return 443 as
indicated in your list above.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 11:53:21 -0800

So how should we proceed with this work? Should this be done as part of a
6156-bis, or is this WG planning to come up with a 5766-bis that subsumes
6156?

On Thu, Feb 20, 2014 at 9:41 AM, Justin Uberti <[email-masked]> wrote:

>> On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti <[email-masked]>wrote:
>>
>>>
>>> Yeah, that was my thinking as well. If RAF is absent, the refresh
>>> applies to all allocations. If the RAF is specified, the specific
>>> allocations are refreshed/deleted, or an error if the RAF doesn't match the
>>> existing allocations.
>>>
>>
>> 4) ipv4+ipv6 - then it is applicable to both endpoint only and returns
>> 443 if ipv4 OR ipv6 endpoint does not exist;
>>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Feb 2014 15:11:42 -0500

Le 2014-02-20 14:53, Justin Uberti a écrit :
> So how should we proceed with this work? Should this be done as part of
> a 6156-bis, or is this WG planning to come up with a 5766-bis that
> subsumes 6156?

Up to the WG to decide, IMHO.

What's your opinion?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Feb 2014 12:55:02 -0800

Of course that's up to WG.

My personal opinion is that because IPv6 is very deeply integrated into the
core TURN functionality (by RFC 6156), then may be the new RFC5766-bis has
to include IPv6 additions with all new updates. So I'd include it into
5766-bis.

Oleg

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 13:18:54 -0800

The downside of doing 6156-bis is that we now have two documents to
produce. The upside is that the changes can be much more modest, rather
than trying to stuff all of 6156 into 5766-bis.

If it turns out that the changes to 5766-bis are small, I would advocate
doing a separate 6156-bis document. If we end up doing more major surgery,
I think we should probably take the opportunity to produce a combined
document.

On Thu, Feb 20, 2014 at 12:55 PM, Oleg Moskalenko <[email-masked]>wrote:

> My personal opinion is that because IPv6 is very deeply integrated into
> the core TURN functionality (by RFC 6156), then may be the new RFC5766-bis
> has to include IPv6 additions with all new updates. So I'd include it into
> 5766-bis.
>
> Oleg
>
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Feb 2014 16:21:27 -0500

Le 2014-02-20 16:18, Justin Uberti a écrit :
> doing a separate 6156-bis document. If we end up doing more major
> surgery, I think we should probably take the opportunity to produce a
> combined document.

<opinion type="personal">

IMHO, it doesn't make sense to write an IPv4-only RFC in 2014.

</opinion>

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 20 Feb 2014 21:29:28 +0000

> IMHO, it doesn't make sense to write an IPv4-only RFC in 2014.

<opinion type="full agreement" />

Gonzalo

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Feb 2014 13:32:17 -0800

> IMHO, it doesn't make sense to write an IPv4-only RFC in 2014.
I agree with that.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 14:23:45 -0800

OK. Onto the 5766-bis list it goes...