Re: [MMUSIC] Do We Need an ICE Alternative ?

Dear Flemming, all,

As an input to this discussion, I just submitted an I-D identifying some IPv6 use cases which motivate the need to define a new SDP attribute. These use cases cover both multicast and unicast.

The I-D is available at: http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00.

Comments and questions are welcome.

Cheers,
Med

> -----Message d'origine-----
> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 
> De la part de Flemming Andreasen
> Envoyé : mardi 15 novembre 2011 13:49
> À : mmusic
> Objet : [MMUSIC] Do We Need an ICE Alternative ?
> 
> Greetings
> 
> Over the past several years, the MMUSIC WG has developed and 
> standardized ICE (RFC 5245) as the mechanism to enable NAT 
> traversal and 
> IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). 
> Alternative NAT traversal mechanisms exist, and others have been 
> proposed, however they have either been limited to specific 
> deployment 
> topologies (e.g. symmetric RTP or STUN by itself) or required 
> some level 
> of network support (e.g. an ALG of some sort). Similarly, for 
> IPv4/IPv6 
> transition, RFC 4091/4092 (ANAT) defined an alternative solution that 
> was deprecated following MMUSIC and SIPPING WG discssion and 
> consensus 
> at IETF68 (in 2007):
> 
>      http://www.ietf.org/proceedings/68/minutes/mmusic.txt
>      http://www.ietf.org/proceedings/68/minutes/sipping.txt
> 
> Several years have passed and we have been getting more 
> implementation 
> and deployment experience with ICE. However, we have also seen 
> suggestions for alternative solutions, with recent examples including 
> the ALTC draft for IPv4/IPv6 transition and the latching 
> mechanism for 
> NAT traversal:
> 
>      Link to ALTC draft:
>      https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/
> 
>      Link to latching mechanism (Section 5.7 in old version 
> of loopback 
> draft):
>      http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt
> 
> 
> Alternatives, that generally have a more limited scope than ICE, keep 
> popping up every now and then, and it seems that at least some set of 
> people are not happy with the current ICE solution. So, we 
> would like to 
> understand from the working group if there are issues with 
> ICE and if we 
> need to explore alternative solutions for NAT traversal and/or for 
> IPv4/IPv6 transition.
> 
> Our goal as a standards organization is to enable interoperable 
> products, and having multiple different standards for the 
> same problem 
> or multiple different standards for specific instances of a general 
> problem is not conducive to that. If we have to revisit one of the 
> standards for a given problem space, we ought to be careful and 
> understand what are the issues that we have with that standard. 
> Furthermore, if we are to come with alternative solutions for that 
> problem space, we have to ensure a clear understanding of what has 
> changed since the last time we created the standard, what are the new 
> set of requirements to satisfy, and which of the old requirements no 
> longer apply.
> 
> So, we would like to sense the WG for opinions in this matter
> 
> Thanks
> 
>      Flemming and Miguel (MMUSIC chairs)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 