Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Apr 2007 18:20:39 +0100

Guylain,

Yes, that is exactly the intention of micro-lite.

John 

> -----Original Message-----
> From: Guylain Lavoie [mailto:[email-masked]] 
> Sent: 06 April 2007 04:19
> To: [email-masked]
> Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> Hi everyone,
> 
> If I may comment, here is how I see this.
> 
> An endpoint that sends an offer with ICE-micro-lite indicates that he
> wants to perform the micro-lite variation of the protocol and that it
> will not perform ICE-lite or ICE-full. He is only proposing two
> candidates that he knows are always be accessible. 
> ICE-micro-lite is so
> easy compared to ICE-lite or ICE-full that I think its support must be
> mandated in the specification.
> 
> An endpoint supporting ICE-full or ICE-lite that receives an
> ICE-micro-lite offer needs to understand that the offerer will not do
> advance ICE processing. The answerer will then choose between the two
> proposed candidates (IPv4 and IPv6). He must act somewhat like the
> offerer only supported ANAT, not ICE. He must then send back 
> the answer.
> The answerer may indicate support for ICE-micro-lite or ICE-lite or
> nothing if ICE-full is supported. This is only an indication of its
> capabilities to the offerer (like when the answerer can add additional
> supported payload type not present in the offer as permitted by
> rfc3264).
> 
> An endpoint supporting only ICE-micro-lite that receives an 
> ICE-lite or
> ICE-full offer will choose one of the proposed candidates and 
> then send
> back the answer with the indication that he is only doing
> ICE-micro-lite.
> 
> This is all based on the assumption that endpoints which support
> ICE-lite or ICE-full always support ICE-micro-lite.
> 
> In the end, it is all about making sure that ANAT is 
> deprecated as soon
> as possible and that a common and better syntax (ICE) is used by all
> providers. I would rather prefer to support an additional ICE method
> than have to support both ANAT and ICE at the same time.
> 
> By the way, can someone more knowledgeable than me explain 
> why ICE-lite
> cannot include more than one host candidate per component 
> when he knows
> that both are always accessible? Is this an arbitrary decision or is
> there something that does not allow this?
> 
> Regards,
> Guylain Lavoie
> 
> -----Original Message-----
> From: Eric Cooper [mailto:[email-masked]] 
> Sent: April 5, 2007 9:03 PM
> To: Francois Audet; Jonathan Rosenberg; Elwell, John
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> I guess I'm missing something here...
> 
> When a micro-lite ICE implementation makes an offer, is it prepared to
> perform full ICE processing if the answer doesn't indicate support for
> micro-lite?
> 
> I would have thought not, because I thought the whole point of
> micro-lite was that full ICE or even ICE-lite was too complicated.
> However, I can't reconcile that guess with your statement below that
> full ICE is the default.
> 
> What did I miss?
> 
> Thanks,
> 
> Eric.
> 
> 
> 
> ----- Original Message -----
> From: "Francois Audet" <[email-masked]>
> To: "Jonathan Rosenberg" <[email-masked]>; "Elwell, John"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, April 05, 2007 8:09 PM
> Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> 
> Jonathan,
> 
> This proposal would NOT attempt to solve NAT traversal problem.
> 
> In order to work, the "default" would be to use FULL ICE. Only if
> both sides indicate support for Microlite would it be used. Otherwise,
> Normal ICE would be done.
> 
> In order to advertize Microlite, you'd have to know that you are not
> behind a NAT (and so would the other side).
> 
> That proposal would support RFC 3484 fine.
> 
> Again, it would only be applicable when there is no NAT.
> 
> It is indeed semantically equivalent to ANAT, but it has 
> the advantage that it is compatible with full-ICE (i.e,
> if the other side doesn't support microlite). 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]] 
> > Sent: Thursday, April 05, 2007 05:22
> > To: Elwell, John
> > Cc: [email-masked]
> > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition
> > 
> > John,
> > 
> > I think this defeats the entire purpose of why we had 
> > selected ICE to deprecate ANAT. What you are proposing below 
> > is nothing more than a syntactic transformation of ANAT into 
> > ICE. This loses all of the benefits ICE brings (dynamic path 
> > selection, ability to run RFC 3484, etc.), and also 
> > introduces a mode that will not interoperate properly with 
> > regular ICE endpoints. Remember, the reason ice-lite requires 
> > an implementation to receive checks and respond to them, is 
> > that this is necessary for the full ice implementation to 
> > achieve nat traversal. With your proposal, a full ICE 
> > implementation would get no NAT traversal benefits when 
> > communicating with an ice micro-lite endpoint.
> > 
> > -Jonathan R.
> > 
> > Elwell, John wrote:
> > 
> > > There was strong consensus at IETF68 to deprecate ANAT and 
> > use ICE as 
> > > the sole way of negotiating between IPv4 and IPv6 for 
> > media. However, 
> > > there was some concern about this raising the bar too high 
> > for those 
> > > who require to support IPv6 ahead of full ICE. While many 
> > markets may 
> > > require ICE for NAT traversal before they require IPv6, there are 
> > > certain customers demanding
> > > IPv6 transition capabilities at an early stage, and 
> needing to do a 
> > > full ICE implementation to satisfy these customers can be 
> > undesirable.
> > > 
> > > To satisfy this market, the requirement is for an offer to 
> > include two 
> > > candidates, one IPv4 and the other IPv6. For backwards 
> > compatibility 
> > > with
> > > IPv4 non-ICE implementations, the IPv4 candidate would be 
> > the default. 
> > > The answerer should be able to select one of these and the 
> > call should 
> > > be able to continue without a connectivity check. Removal of 
> > > connectivity checks would considerably simplify the 
> > implementation of 
> > > ICE for IPv4/IPV6 negotiation in these environments. 
> Compatibility 
> > > with full or lite ICE implementations would have to be 
> > provided, of course.
> > > 
> > > Thus we would really only use the SDP enhancements of ICE, 
> > and not the rest.
> > > Compared with ANAT it has the advantages of better backward 
> > > compatibility with existing IPv4 devices and being a step 
> > on the path towards full ICE.
> > > 
> > > ICE lite goes some way to lowering the bar for implementing 
> > ICE, but 
> > > it does not solve the present problem for two reasons:
> > > 1) An ICE lite implementation cannot propose two candidates.
> > > 2) An ICE lite implementation is still required to support 
> > > connectivity checks as a server.
> > > 
> > > It seems that the requirements above could be supported 
> by a fairly 
> > > small change to ICE, along the following lines. I will 
> call this an 
> > > ICE "micro-lite" implementation.
> > > 
> > > When sending an offer, a dual stack ICE "micro-lite" 
> implementation 
> > > would include two candidates, one based on IPv4 (the default 
> > > candidate) and the other based on IPv6. It would also 
> > include a flag 
> > > (e.g., an option tag) to indicate that it supports only 
> > "micro-lite" 
> > > and therefore will not do connectivity checks. The answerer would 
> > > choose the IP protocol and respond with an IP address for that 
> > > protocol in the c-line. If IPv6 is chosen, the offerer 
> > would need to 
> > > do a further offer to promote its IPv6 address and port to 
> > the m/c line.
> > > 
> > > If the answerer is a full (or lite) implementation, it 
> > would use the 
> > > received "micro-lite" indicator to behave as above and suppress 
> > > testing. If the offerer is a full implementation, it sees 
> that the 
> > > answerer does not support full or lite ICE (because it does 
> > not return 
> > > any candidate lines) but would use the fact that the c-line 
> > contains 
> > > an IPv6 address to select its IPv6 host candidate, use it 
> > in the m/c 
> > > line of a new offer, and suppress testing.
> > > 
> > > The above would represents quite a small change to ICE and could 
> > > probably be accommodated in the ICE RFC rather than a 
> > separate RFC. In 
> > > this way it would be easier to force support of micro-lite 
> > by all ICE implementations.
> > > 
> > > As a further enhancement, perhaps ICE-lite could allow the 
> > inclusion 
> > > of two candidates, where one is IPv4 and the other is IPv6. ICE 
> > > micro-lite would then be a subset of ICE-lite. There would 
> > then be a 
> > > natural evolution path for implementations, from 
> > micro-lite, via lite to full ICE.
> > > 
> > > John
> > > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ 
> > 07054-2711
> > Cisco Systems
> > [email-masked]                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic