Subject: [tsvwg] feedback on draft-thornburgh-adobe-rtmfp-04

From: Cameron Byrne <[email-masked]>
Date: Sat, 9 Mar 2013 20:42:05 -0800

Hi,

I have some strong concerns about this I-D and RTMFP in general with
regards to how they treat communication between IPv4-only and
IPv6-only systems.

Given the reality that RIPE and APNIC are both out of IPv4, it is
unacceptable to introduce a protocol that bifurcates the Internet into
those that have IPv4 and those that have IPv6.  AFAIK,
draft-thornburgh-adobe-rtmfp-04 only accounts for the ability talk
within a single address family.

Similar solutions like ICE (rfc5245) solve this problem by using TURN,
and the general approach would be to DNS64 / NAT64

I do not believe this I-D should be adopted as WG item and i do not
think it is eligible for standards tracks qualification since it
communicates IPv4 literals / referrals as its fundamental design, thus
not accounting for the scenarios in RFC 6144 and explicitly breaking
network, like mine, that use the proposed standard RFC 6146.

CB

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 11 Mar 2013 12:26:31 -0700

hi Cameron. thanks for your feedback.

RTMFP is fundamentally an endpoint-to-endpoint transport protocol (like TCP), and is typically carried in UDP datagrams. a practical RTMFP implementation, such as that in Flash Player, will typically have multiple interfaces for one protocol instance/entity, including one or more interfaces for directly-attached IPv4, one or more for directly-attached IPv6, and potentially one or more TURN proxy interfaces (in the case of Flash Player, a pre-RFC version of TURN), all of which can be operable simultaneously.

like any other protocol that runs over IP, RTMFP can't send a datagram directly to an IPv6 destination if it only has IPv4 physical interfaces (or vice versa).  DNS64 is applicable to applications that always do DNS lookups to discover the addresses with which to communicate (typically a server of some sort -- certainly not an ephemeral peer).  in those situations, an application using RTMFP would learn the magical translated address with which to communicate and could establish a session in the normal way through the translator.  RTMFP's forwarder/redirector mechanism (FIHello/Redirect -- the only chunks containing socket address literals) isn't required for general session establishment.

the forwarder/redirector mechanism enables additional functionality (P2P lookup/introduction and UDP hole-punching support for NAT and firewall traversal) beyond the application types for which the DNS64 approach is intended.

note also that an FIHello or a Redirect could come in an IPv4 packet but contain IPv6 socket addresses, or vice versa.  a Redirect could contain a mix of IPv4 and IPv6 addresses.  the FIHello mechanism can be used by a server (in a manner similar to how http://cc.rtmfp.net works) to discover the reflexive address of the other address family (if present) of a connected client.  an application using RTMFP can also use ICE, if it desires, and share the same socket(s) for RTMFP and ICE, since the likelihood of a STUN packet being decryptable/decodable as a valid RTMFP packet is very very small.  

-michael thornburgh

> From: Cameron Byrne
> Sent: Saturday, March 09, 2013 8:42 PM
> 
> Hi,
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 18:52:37 -0700

Michael,

> RTMFP is fundamentally an endpoint-to-endpoint transport protocol (like TCP), and is typically carried in UDP datagrams. a practical RTMFP implementation, such as that in Flash Player, will typical…

no, i don't think RTMFP is like TCP.  I think it is more akin to ICE, no?

A typical flash player has multiple interfaces?  Can you explain more?
I figure most flash players have one functional interface (not
counting overlay networks like 6to4 that are hazardous)

> like any other protocol that runs over IP, RTMFP can't send a datagram directly to an IPv6 destination if it only has IPv4 physical interfaces (or vice versa).  DNS64 is applicable to applications…

Right, the lack of DNS lookup (no DNS64) and lack of TURN support are
exactly my object to RTMFP.  These choices result in a design flaw
IMHO.

We cannot bring to this working group or to standards track a protocol
like this.  Especially when we already have ICE.  I know some people
think its funny to say "the great thing about standards is that there
are so many to choose from", but i do not think it is funny.

Is there something specific that RTMFP brings to the table that cannot
be achieved with ICE / TURN / STUN ?  AFAIK, RTMFP is an inferior
subset of ICE.

> note also that an FIHello or a Redirect could come in an IPv4 packet but contain IPv6 socket addresses, or vice versa.  a Redirect could contain a mix of IPv4 and IPv6 addresses.  the FIHello mecha…

I can't parse any of that.  What is the point you are trying to make?
An RTMFP client can also run ICE?  Ok, why do i need RTMFP client?
Why can't i just run ICE?

In summary, i object to this being a WG document.  There is no clear
reason why we need RTMFP and ICE.  ICE is already the relevant
standard and appears fit for purpose.  RTMFP is not fit for purpose
since it has no mechanism for working in a world with IPv4-only and
IPv6-only hosts that must communicate with one another.  Thus, RTMFP
is a step backwards.

But, please let me know if i am misunderstanding something.  But,
honestly, as a mobile network operator with IPv6-only host i am quite
familiar with RTMFP and i have a strong operational bias against  the
protocol and find it extremely harmful for IPv6 adoption.

Cameron

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 11 Mar 2013 21:08:55 -0700

replies inline.

> From: Cameron Byrne
> Sent: Monday, March 11, 2013 6:53 PM
> 
> Michael,
> 
> > RTMFP is fundamentally an endpoint-to-endpoint transport protocol (like TCP), and is typically
> carried in UDP datagrams. a practical RTMFP implementation, such as that in Flash Player, will
> typically have multiple interfaces for one protocol instance/entity, including one or more interfaces
> for directly-attached IPv4, one or more for directly-attached IPv6, and potentially one or more TURN
> proxy interfaces (in the case of Flash Player, a pre-RFC version of TURN), all of which can be
> operable simultaneously.
> >
> 

no. RTMFP is a complete connection-oriented transport protocol, like TCP or SCTP, including parallel message-oriented data flows, flow control, congestion control, variable delivery reliability for messages, etc.  RTMFP sessions between two endpoints are normally established with a 4-way handshake (Figure 8 in Section 3.5.1.1).

the protocol includes additional facilities (the FIHello and Redirect chunks) for implementing P2P lookup/intro, UDP hole-punching, and clustering/load balancing.
 
> counting overlay networks like 6to4 that are hazardous)

Flash Player's RTMFP implements one interface each for an IPv4 INADDR_ANY socket, an IPv6 IN6ADDR_ANY socket, and optionally a (pre-RFC version of) TURN proxy.  the same RTMFP instance/entity/identity can be reached through any of the socket addresses associated with any of those interfaces.

> > like any other protocol that runs over IP, RTMFP can't send a datagram directly to an IPv6
> destination if it only has IPv4 physical interfaces (or vice versa).  DNS64 is applicable to
> applications that always do DNS lookups to discover the addresses with which to communicate (typically
> a server of some sort -- certainly not an ephemeral peer).  in those situations, an application using
> RTMFP would learn the magical translated address with which to communicate and could establish a
> session in the normal way through the translator.  RTMFP's forwarder/redirector mechanism
> (FIHello/Redirect -- the only chunks containing socket address literals) isn't required for general
> session establishment.
> >
> 

disagree.  using DNS is for the application, not the transport protocol.  the application uses DNS to discover one (or more) candidate addresses for an endpoint, and gives those addresses to the transport protocol to establish the connection to the endpoint.

RTMFP (like any other UDP-based protocol) can be used with a TURN proxy.  a TURN proxy is simply a remote UDP socket.

> are so many to choose from", but i do not think it is funny.

note that at this time, this specification is on the Informational track and documents a vendor-supplied network transport protocol that is in active use and is widely deployed in the Internet today.  TSVWG is being informed as this working group has a relevant audience that would find RTMFP's features of interest/value, and that should be informed of the specification's existence.

> be achieved with ICE / TURN / STUN ?  AFAIK, RTMFP is an inferior

RTMFP is a connection-oriented transport protocol.  see my comment above.  it is not an "ICE replacement", although ICE should not be needed when using RTMFP's facilities for P2P lookup/intro & UDP hole-punching.

> > the forwarder/redirector mechanism enables additional functionality (P2P lookup/introduction and UDP
> hole-punching support for NAT and firewall traversal) beyond the application types for which the DNS64
> approach is intended.
> >
> > note also that an FIHello or a Redirect could come in an IPv4 packet but contain IPv6 socket
> addresses, or vice versa.  a Redirect could contain a mix of IPv4 and IPv6 addresses.  the FIHello
> mechanism can be used by a server (in a manner similar to how http://cc.rtmfp.net works) to discover
> the reflexive address of the other address family (if present) of a connected client.  an application
> using RTMFP can also use ICE, if it desires, and share the same socket(s) for RTMFP and ICE, since the
> likelihood of a STUN packet being decryptable/decodable as a valid RTMFP packet is very very small.
> >
> 

the point is: should you really want to use ICE for setting up RTMFP sessions (instead of, or in addition to, the facilities RTMFP provides), you can.

> IPv6-only hosts that must communicate with one another.  Thus, RTMFP

as i mentioned previously, RTMFP works like any other transport protocol in application contexts where DNS64 is appropriate (just like TCP).  RTMFP also has additional features and facilities that can do interesting things in application contexts where DNS64 is not appropriate (like peer-to-peer scenarios, where you wouldn't be looking up peers in the DNS anyway).

> protocol and find it extremely harmful for IPv6 adoption.

i think you are misunderstanding what RTMFP is and what it's for.  i hope my statements above have helped change that.  if not, i'll be talking briefly about RTMFP and this I-D in thursday's TSVWG session, and i invite you to read the I-D with my statements in mind (in particular, sections 1, 3.1, 3.5 and 3.6).

-michael thornburgh

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 12 Mar 2013 00:40:29 -0400

On 3/12/2013 12:08 AM, Michael Thornburgh wrote:
> 
> note that at this time, this specification is on the Informational
> track and documents a vendor-supplied network transport protocol that
> is in active use and is widely deployed in the Internet today.  TSVWG
> is being informed as this working group has a relevant audience that
> would find RTMFP's features of interest/value, and that should be
> informed of the specification's existence.
> 

And "thank you" Michael (and Adobe) for working on this!

I don't know how it was misunderstood as having anything to do
with ICE and DNS64, but I would suggest actually looking at the
document before throwing stones!

-- 
Wes Eddy
MTI Systems

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 22:03:34 -0700

> document before throwing stones!

Perhaps i was thinking more generically about rtmp as problematic without
decomposing out rtmfp.

CB