Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

["Karl Stahl" <[e-mail]>]

No and this draft cannot be approved without the generalization I have pointed out.

I really don’t understand why we are having this resistance.

 

Already the second paragraph of the Abstract states:

The TURN protocol was designed to be used as part of the ICE

   (Interactive Connectivity Establishment) approach to NAT traversal,

   though it also can be used without ICE.

 

And further in the Introduction

TURN was designed as one piece in the larger ICE approach to NAT

   traversal.  Implementors of TURN are urged to investigate ICE and

   seriously consider using it for their application.

 

 

I cannot imagine that there is some WG decision to hinder ICE usage for network provided TURN servers EXCEPT FOR EXACTLY BRANDON’S NETWORK. 

 

For now I refrain from writing/debating more – which would override the effort of what is required to generalize as asked. 

Please be happy that most of the dual allocation work done, can be reused to fulfill the generalization.

 

Tiru and Brandon are encouraged to read the TRAM charter … 

 

/Karl

 

 

Från: Simon Perreault [mailto:[e-mail]] 
Skickat: den 21 mars 2018 18:13
Till: Brandon Williams
Kopia: Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl; [e-mail]
Ämne: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

 

2018-03-21 17:05 GMT+00:00 Brandon Williams <[e-mail]>:

Chairs, Any suggestions on approach?

 

The proposal on the table is for Karl+Olle to write their idea into a new draft.

 

Karl+Olle, can you guys live with that?

 

Simon

 

**********************

 

Let me explain more clearly why multiple allocations is needed:

 

ICE is about finding all/many paths for the media, e.g. with the help of

TURN servers.

Those paths are not over ONE IPv4 network, over ONE IPv6 network or EXACTLY

ONE OF EACH.

If fact, it is more common that you have several IPv4 networks paths.

 

Now that we have network provided TURN servers, you only ask for Allocation

once (contrary to application provided TURN servers, where you can be

directed to Allocate several times.) and thus we need all relay addresses in

one allocation request.

 

Wasn't that the reason dual allocation was requested? The need for multiple

allocation is stronger!

 

Please address this, e.g. like below (seems you are almost there).

 

/Karl

 

 

******************* Previous *******************

 

Allowing a turn allocation to return multiple relayed transport addresses,

beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different

interfaces/network segments), seems like very small step now when the dual

allocation was put in place in this draft. We certainly need it (some

reasons below) if TURN is going to be used where needed and we cannot wait

for any additional draft.

 

Seems like it is sufficient to extent this table (found in draft 14) with 3

new values (as shown):

 

16.  STUN Attributes

 

   This STUN extension defines the following attributes:

 

     0x000C: CHANNEL-NUMBER

     0x000D: LIFETIME

     0x0010: Reserved (was BANDWIDTH)

     0x0012: XOR-PEER-ADDRESS

     0x0013: DATA

     0x0016: XOR-RELAYED-ADDRESS

     0x0017: REQUESTED-ADDRESS-FAMILY

     0x0018: EVEN-PORT

     0x0019: REQUESTED-TRANSPORT

     0x001A: DONT-FRAGMENT

     0x0021: Reserved (was TIMER-VAL)

     0x0022: RESERVATION-TOKEN

     TBD-CA: ADDITIONAL-ADDRESS-FAMILY

ADDITIONAL-ADDRESS-ALL

ADDITIONAL-ADDRESS-ALLV4

ADDITIONAL-ADDRESS-ALLV6

     TBD-CA: ADDRESS-ERROR-CODE

     TBD-CA: ICMP

 

Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very

little text seems to be added for generalization to  ADDITIONAL-ADDRESS-xxx.

Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused.

 

ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client.

 

Check! - We need this now.

 

Thanks,

Karl