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

From: "Elwell, John" <[email-masked]>
Date: Mon, 02 Apr 2007 15:53:36 +0100

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Apr 2007 08:21:46 -0400

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.

-- 
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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Apr 2007 19:09:23 -0500

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.
> > 
> > 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.
> > 
> > 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:
> > 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.
> > 
> > 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
> > 
> 
> --

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 5 Apr 2007 21:02:36 -0400

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,

---

From: "Guylain Lavoie" <[email-masked]>
Date: Thu, 5 Apr 2007 23:18:30 -0400

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

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,

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 6 Apr 2007 09:58:40 -0500

You could do what you said, but then you wouldn't be able to do NAT
traversal. 
And, more importantly, the other end wouldn't either.

> Sent: Thursday, April 05, 2007 18:03
> To: Audet, Francois (SC100:3055); Jonathan Rosenberg; Elwell, John
> Cc: [email-masked]
> 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.
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Apr 2007 09:14:13 -0400

inline.

> there something that does not allow this?

It is most certainly NOT arbitrary. ICE-lite falls apart when you do this.

The reason is as follows. Remember that an important part of ICE 
processing is this 'fix-up' operation, whereby, if the candidate 
selected by ICE is not matching the m/c-line, the controlling agent does 
an updated offer to make them match. This was deemed important for 
backwards compatibility with lots of middleboxes that want to see media 
sent to the target of the m/c-line.

With ice-lite, since there is only ever one candidate, it always matches 
the m/c-line, and so the agent never needs to do fix-ups.

Now, if you allow multiple candidates, what happens if both sides are 
ice-lite, but a candidate is selected that does NOT match the m/c-line? 
Well, now you need to do the fix-up re-invite. So, you'd now lose the 
property that, when both sides are ice-lite, you basically don't do ICE 
at all. You'd have to do some third subset of ICE.

So, let us continue down this line of thought. What if we specify that? 
What if, with ice-lite, you still do some kind of third mode when both 
sides are ice-lite, so that the fix-up reinvite is done? Well, to do the 
fix-up, you need to select a controlling and controlled node. Folks will 
recall that, in certain 3pcc cases, it is possible for both agents to 
think they are controlled, or both to think they are controlling. THe 
fix for this in ice-15 is to use flags in the STUN checks themselves to 
sort out this ambiguity. However, we wouldn't be having any checks here, 
so we'd have an unresolved ambiguity.

-Jonathan R.