Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt

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

Francois,

I think something along these lines would be useful, but see comments below.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 18 April 2007 23:03
> To: Jean-Francois Mule; [email-masked]; Jonathan Rosenberg
> Cc: Colin Perkins; Joerg Ott
> Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt
> Importance: High
> 
> My comments for WGLC are included below:
> 
> In order to be able to use ICE as the mechanism for supporting a
> dual-stack
> IPv4/IPv6 implementation, some minor changes need to be made 
> to ICE-15.
> Specifically, 
> for the case where BOTH sides are using ICE-lite.
> 
> The procedures when one or both sides are NOT using ICE-lite are OK as
> is in ICE-15.
> 
> Using section 5 of ICE-15 as a basis.
> 
> A sends offer to B. A uses ICE-lite, but it is dual stack, so 
> the offer
> looks like 
> this:
> 
> Offer:
> 
> 	m=IPv4              <- Assumption is that IPv4 is morelikely to
> succeed than IPv6
> 	candidate 1=IPv6
> 	candidate 2=IPv4
> 	a=ice-lite
[JRE] ICE-15 is ambiguous as to whether multiple candidates are allowed with
ice-lite. I believe the intention is to clarify this by saying that only one
candidate is allowed, which would then invalidate this example. However, I
do agree that it could be useful to have this capability and the procedures
you describe below.

> 
> B receives the offer, it is also using ice-lite and is also 
> dual stack.
> 
> It sends an answer:
> 
> 	m=IPv4
> 	candidate 1=IPv6
> 	candidate 2=IPv4
> 	a=ice-lite
> 
> According to section 5 today it would result in having "NO 
> CONNECTIVITY
> CHECK".
> 
> The current wording says "ICE cannot proceed", which I think is
> innacurate since the 
> candidates have already been sent, so ICE has already proceeded to a
> certain point. I think it 
> needs to be clarified is that it "ICE does not proceed with the
> connectivity check".
> 
> According to section 5 again, it would result in having the IPv4
> selected instead of the 
> IPv6 (i.e., the m line).
> 
> That's NOT the behavior we want. What we want is in this case to have
> both sides use the candidates 
> and the RFC 3484 procedures. I would like to see some guidance around
> using RFC 3484 procedures.
> 
> One easy way for B to ensure that it's choice is selected, is 
> to respond
> with this answer
> instead:
> 
> 	m=IPv6                <- i.e., forcing the other side to use the
> IPv6 address
> 	candidate 1=IPv6      <- I'm not sure we actually need this
> line?
> 	a=ice-lite            <- This is to tell A that it understood
> ICE
> 
> It might also be useful in this case, for the second offer answer
> (normal in ICE) to
> proceed to "lock" on the IPv6 address and help middleboxes. Therefore,
> the second offer
> answer would look like:
> 
> Offer:
> 	m=IPv6              
> 
> Answer: 
> 	m=IPV6
> 
> I believe that if we do this, we will have addressed the requirements
> for dual-stack.
> 
> > -----Original Message-----
> > From: Jean-Francois Mule [mailto:[email-masked]] 
> > Sent: Thursday, March 29, 2007 08:07
> > To: [email-masked]
> > Cc: Colin Perkins; Joerg Ott
> > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt
> > 
> > 
> > This is to announce a Working Group Last Call on ICE 
> > draft-ietf-mmusic-ice-15.txt.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
> > 
> > This WGLC will end on Friday April 20.
> > 
> > Please mail all your final comments to the author and the 
> > mmusic mailing list.
> > 
> > Jean-Francois -- As WG co-chair
> > [email-masked] 
> > 
> > 
> > 
> > _______________________________________________
> > 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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Apr 2007 10:12:27 -0500

Agree. I am proposing that we make the change to allow multiple
candidates for
IPv4/IPv6. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, April 20, 2007 01:09
> To: Audet, Francois (SC100:3055); Jean-Francois Mule; 
> [email-masked]; Jonathan Rosenberg
> > IPv4/IPv6 implementation, some minor changes need to be made to 
> > ICE-15.
> > Specifically,
> > A sends offer to B. A uses ICE-lite, but it is dual stack, so the 
> > offer looks like
> > this:
> > 
> > Offer:
> > 
> [JRE] ICE-15 is ambiguous as to whether multiple candidates 
> are allowed with ice-lite. I believe the intention is to 
> clarify this by saying that only one candidate is allowed, 
> which would then invalidate this example. However, I do agree 
> that it could be useful to have this capability and the 
> procedures you describe below.
> 
> > 
> > B receives the offer, it is also using ice-lite and is also dual 
> > stack.
> > 
> > It sends an answer:
> > 
> > 	m=IPv4
> > 	candidate 1=IPv6
> > 	candidate 2=IPv4
> > 	a=ice-lite
> > 
> > CONNECTIVITY CHECK".
> > innacurate since the candidates have already been sent, so ICE has 
> > already proceeded to a certain point. I think it needs to 
> be clarified 
> > is that it "ICE does not proceed with the connectivity check".
> > 
> > both sides use the candidates and the RFC 3484 procedures. I would 
> > like to see some guidance around using RFC 3484 procedures.
> > 
> > One easy way for B to ensure that it's choice is selected, is to 
> > respond with this answer
> > instead:
> > 
> > (normal in ICE) to proceed to "lock" on the IPv6 address and help 
> > middleboxes. Therefore, the second offer answer would look like:
> > 
> > Offer:
> > 	m=IPv6              
> > 
> > Answer: 
> > 	m=IPV6
> > 
> > > Please mail all your final comments to the author and the mmusic 
> > > mailing list.
> > >