Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04

["Alfred E. Heggestad" <aeh@xxxxxx>]

inline.

Jonathan Rosenberg wrote:
> inline.
>
> Alfred E. Heggestad wrote:
>
> > Dan Wing wrote:
> >
> > > > * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN 
> > > > server:
> > > >
> > > >   The STUN request contains the new FINGERPRINT attribute, but this
> > > >   attribute is not supported by the STUN server (Vovida.org 0.96),
> > > >   hence the response is dropped.
> > >
> > > That shouldn't be a problem for the RFC3489bis-compliant STUN 
> > > client.  The
> > > primary purpose of this attribute is to provide an additional 
> > > distinguisher
> > > for STUN/non-STUN packets.  That is, there isn't any reason for an
> > > RFC3489bis-compliant STUN server to validate or check for that 
> > > attribute.
> > > Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a 
> > > RFC3489
> > > STUN server won't return it.  Thus, if the RFC3489bis client wants to
> > > interoperate with a RFC3489 STUN server, it needs to understand the
> > > responses sent by a RFC3489 server.
> >
> >
> > many thanks for your answer. ok I understand that the new FINGERPRINT
> > attribute to distinguish between STUN and non-STUN packets.
> >
> > prior to sending a STUN request, the STUN client cannot know which
> > version of the spec the STUN server supports. so it can e.g. try to
> > send a bis-04 compliant STUN request include the FINGERPRINT attrib
> > and if it times out, then try to send a STUN request ala RFC3489..
>
> Actually I have a better idea. I can change the value of FINGERPRINT to 
> be in the range of optional attributes. This way, it will be ignored by 
> an older RFC3489 implementation. Since muxing is not an issue in the 
> classic rfc3489 stun usage, its fine.

yes, that makes sense. the FINGERPRINT (or CRC32) attribute could be
optional, but RECOMMENDED for checking the validity of a STUN message.
the STUN server will always include this attribute for responses
to rfc3489bis clients.



> > yes you are right. I have updated my STUN server now to support both
> > flavours. although there is a (tiny) chance that the first 4 bytes
> > of the TID generated by a RFC3489-client actually contains 0x2112a442.
> >
> > but I guess, if the a STUN request fails for this reason the client
> > will just retry until it works..
>
> It will be really, really rare. Given a packet loss of 10%, its actually 
> more likely that all of teh requests in a transaction are lost than it 
> is you'll run into this overlap.

ok fair enough..



/alfred

> Thanks,
> Jonathan R.