Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt)

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Jul 2007 12:01:43 +0300

Hi,

yes, it seems that a simple solution would be best. I suggest we do as 
follows. We do not allow multiple addresses per allocation. Instead, if 
a client wants to allocate an IPv4 and an IPv6 address at a relay, it 
performs two different allocations. This way, we do not add any extra 
complexity to the protocol.

Regarding address types, I suggest that we keep things as they are. That 
is, we define the IPv4 and IPv6 address families, which are the ones 
that people will definitively use.

Cheers,

Gonzalo

Philip Matthews wrote:
> My concern about the SourceAddress and DestinationAddress attributes is 
> partly overhead and partly additional complexity in TURN.
> 
> The first could be addressed by enhancing the SetActiveDestination 
> indication to specify the default sending/receiving address so that 
> these attributes can be eliminated once the ICE connectivity checks are 
> finished.
> 
> The second is just because I see STUN and TURN as getting more and more 
> complex to handle marginal cases.
> Personally, I don't see a reasonable use-case for a TURN relay with more 
> than one IPv4 address and one IPv6 address. Unless, some can present 
> one, I suggest we design for that case and not insert things that are 
> only really useful in future cases that currently seem unlikely.
> As suggested below, it might be possible to infer the address of the 
> TURN-relay-to-destination portion of the path from the address or header 
> used on the TURN relay-to-client portion of the path.  I am not 
> convinced this is really foolproof, but if it is, then I think this is 
> might be a simpler solution than defining the new attributes.
> 
> - Philip
> 
> 
> On 30-May-07, at 02:23 , Gonzalo Camarillo wrote:
> 
>> Hi,
>>
>> we agreed on defining the address family as Global IPv6 Unicast 
>> Address. If, in the future, we decide to define new families (as you 
>> pointed out), we will need the source-in-send and destination-in-data. 
>> Therefore, I suggest we are explicit from the beginning and add them 
>> from day one.
>>
>> This was my understanding of our discussions, actually.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> Rémi Denis-Courmont wrote:
>>> On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote:
>>>> Hi,
>>>>
>>>>> I do not have any very strong opinion. One option would be to 
>>>>> enforce a
>>>>> single
>>>>> server address per family and per allocation;
>>>> I believe we have rough consensus on using a single address per family,
>>>> and on having the possibility of having multiple addresses per 
>>>> allocation.
>>> Fine, then source-in-Send and destination-in-Data are not really needed.
>>
>>
> 

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 06 Jul 2007 09:57:40 +0300

Hi,

I have put together a new revision of this draft. Until it appears in
the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-behave-turn-ipv6-03.txt

Besides addressing a few issues that were identified a while ago, I have
added the following paragraph to this revision:

    For simplicity reasons, STUN relay servers are designed to allocate a
    single address per allocation request.  Therefore, Allocate Requests
    cannot carry more than one REQUESTED-ADDRESS-TYPE attribute.
    Consequently, a client that wishes to allocate more than one address
    at a STUN relay server (e.g., an IPv4 and an IPv6 address) needs to
    perform several allocation requests (one allocation request per
    address).

I believe it captures the result of our mailing list discussions. Even
though this was the approach the draft took from the beginning, it has
been good to have explicit discussions on the list about potential
optimizations such as the allocation of multiple addresses per
allocation, which we have agreed not to implement.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Hi,
> 
> yes, it seems that a simple solution would be best. I suggest we do
> as follows. We do not allow multiple addresses per allocation.
> Instead, if a client wants to allocate an IPv4 and an IPv6 address at
> a relay, it performs two different allocations. This way, we do not
> add any extra complexity to the protocol.
> 
> Regarding address types, I suggest that we keep things as they are.
> That is, we define the IPv4 and IPv6 address families, which are the
> ones that people will definitively use.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
> Philip Matthews wrote:
>> My concern about the SourceAddress and DestinationAddress
>> attributes is partly overhead and partly additional complexity in
>> TURN.
>> 
>>  indication to specify the default sending/receiving address so
>> that these attributes can be eliminated once the ICE connectivity
>> checks are finished.
>> 
>> The second is just because I see STUN and TURN as getting more and
>>  more complex to handle marginal cases. Personally, I don't see a
>> reasonable use-case for a TURN relay with more than one IPv4
>> address and one IPv6 address. Unless, some can present one, I
>> suggest we design for that case and not insert things that are only
>> really useful in future cases that currently seem unlikely. As
>> suggested below, it might be possible to infer the address of the 
>> TURN-relay-to-destination portion of the path from the address or 
>> header used on the TURN relay-to-client portion of the path.  I am
>> not convinced this is really foolproof, but if it is, then I think
>> this is might be a simpler solution than defining the new
>> attributes.
>> 
>> - Philip
>> 
>> 
>>> Address. If, in the future, we decide to define new families (as
>>> you pointed out), we will need the source-in-send and 
>>> destination-in-data. Therefore, I suggest we are explicit from
>>> the beginning and add them from day one.
>>> 
>>>>>> I do not have any very strong opinion. One option would be
>>>>>> to enforce a single server address per family and per
>>>>>> allocation;
>>>>> I believe we have rough consensus on using a single address
>>>>> per family, and on having the possibility of having multiple
>>>>> addresses per allocation.
> _______________________________________________ Behave mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/behave
>