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

> -----Original Message-----
> From: Olle E. Johansson [mailto:oej@edvina.net]
> Sent: Tuesday, March 20, 2018 8:35 PM
> To: Karl Stahl <karl.stahl@ingate.com>
> Cc: Olle E Johansson <oej@edvina.net>; Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org
> Subject: Re: Multiple allocations SV: [tram] I-D Action: draft-ietf-tram-turnbis-
> 15.txt
> 
> 
> > On 20 Mar 2018, at 20:55, Karl Stahl <karl.stahl@ingate.com> wrote:
> >
> >> This revision addresses comments from Mark, Karl and Noriyuki Torii.
> > My comment about need for multiple allocations is NOT addressed.
> >
> > 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.
> 
> I agree with Karl here, for network-provided turn servers (which is not defined in
> the terminology section here on in 8155) I think there are use cases for multiple
> addresses in multiple families.

The WG has only agreed on dual allocation, this is a new requirement for a specific deployment scenario. 
You may want to submit a new draft (just like we did for RFC8155). 

-Tiru

> 
> I also understand that this will make the draft more complex. Consider the case
> where a turn server have two IPv4 networks and one IPv6 and have run out of
> possible allocations on one IPv4 network - should it send what’s available or
> send an error message and fail completely?
> 
> Regardless, this is a good time to fix this.
> 
> /O
> 
> 
> >
> > 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
> >
> >> -----Original Message-----
> >> From: Karl Stahl [mailto:karl.stahl@ingate.com]
> >> Sent: Sunday, March 4, 2018 10:36 PM
> >> To: 'Marc Petit-Huguenin' <petithug@acm.org>; Konda, Tirumaleswar
> >> Reddy <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org
> >> Subject: SV: [tram] Review of dual allocation in TURNbis-11
> >>
> >> Hi,
> >>
> >> When we now have "dual allocation" into this draft (I see on page 26:
> >> "If
> > the
> >> client wishes to obtain one IPv6 and one IPv4 relayed transport
> >> address
> > then
> >> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it")
> >> can we not generalize that further and allow MORE THAN ONE relayed
> >> transport address (of any family) in response to an allocation?
> >>
> >> I mean that a TURN server could have several relay interfaces at
> >> different
> > IP-
> >> addresses into different networks - not just the Internet, but also a
> >> VoIP (higher quality) network e.g. by some triple play service
> >> provider, an IMS network or some branch office network.
> >>
> >> I think this is specifically important for network provided/auto
> > discovered
> >> turn servers (application provided turn servers could instead just
> >> list
> > several
> >> turn servers).
> >>
> >> I saw someone snipped this about "SINGLE relayed transport address
> >> per allocation request"
> >>>> https://tools.ietf.org/html/rfc6156#section-3
> >>>> <snip>
> >>>>
> >>>>   TURN servers allocate a single relayed transport address per
> >>>>   allocation request.  Therefore, Allocate requests cannot carry more
> >>>>   than one REQUESTED-ADDRESS-FAMILY attribute.  Consequently, a
> >> client
> >>>>   that wishes to allocate more than one relayed transport address
> >>>> at
> > a
> >>>>   TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
> >>>>   several allocation requests (one allocation request per relayed
> >>>>   transport address).
> >>>> </snip>
> >>
> >> but if that is remedied now, it seems like a small step to generalize
> >> so
> > we can
> >> get multiple relayed transport addresses from one allocate request?
> >>
> >> /Karl
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: tram [mailto:tram-bounces@ietf.org] För Konda, Tirumaleswar
> > Reddy
> > Skickat: den 18 mars 2018 09:51
> > Till: tram@ietf.org
> > Ämne: Re: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> >
> > This revision addresses comments from Mark, Karl and Noriyuki Torii.
> >
> > -Tiru
> >
> >> -----Original Message-----
> >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> >> drafts@ietf.org
> >> Sent: Sunday, March 18, 2018 8:43 AM
> >> To: i-d-announce@ietf.org
> >> Cc: tram@ietf.org
> >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-15.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >> This draft is a work item of the TURN Revised and Modernized WG of
> >> the IETF.
> >>
> >>        Title           : Traversal Using Relays around NAT (TURN): Relay
> > Extensions
> >> to Session Traversal Utilities for NAT (STUN)
> >>        Authors         : Tirumaleswar Reddy
> >>                          Alan Johnston
> >>                          Philip Matthews
> >>                          Jonathan Rosenberg
> >> 	Filename        : draft-ietf-tram-turnbis-15.txt
> >> 	Pages           : 84
> >> 	Date            : 2018-03-18
> >>
> >> Abstract:
> >>   If a host is located behind a NAT, then in certain situations it can
> >>   be impossible for that host to communicate directly with other hosts
> >>   (peers).  In these situations, it is necessary for the host to use
> >>   the services of an intermediate node that acts as a communication
> >>   relay.  This specification defines a protocol, called TURN (Traversal
> >>   Using Relays around NAT), that allows the host to control the
> >>   operation of the relay and to exchange packets with its peers using
> >>   the relay.  TURN differs from some other relay control protocols in
> >>   that it allows a client to communicate with multiple peers using a
> >>   single relay address.
> >>
> >>   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.
> >>
> >>   This document obsoletes RFC 5766 and RFC 6156.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tram-turnbis-15
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-15
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-15
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> > submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> tram mailing list
> >> tram@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tram
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
> >