Subject: [MMUSIC] Re: ICE and IPv6 transition

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 03 Mar 2007 07:15:45 -0500

I'd actually argue that its 'cleaner' to have a single m-line, since 
what we really have here is a single media stream. With ICE, the m-line 
continues to have its regular meaning, and ICE then allows for multiple 
candidates for how to reach it, whether they be different transport 
protocols, different IP addresses, or different IP versions.

I had an idea this morning on a middleground approach which can bring us 
the simplicity of ANAT for simpler cases, yet provide the functionality 
of what ICE can bring for more complex cases.

The idea is to use ice-lite to help. If an endpoint has v4 and v6 but is 
  not natted, it would declare itself as an ice-lite implementation in 
the SDP, and include two candidates - one for v4, one for v6. If they 
call another similar endpoint (dual stack, not natted), that endpoint 
would provide, in its answer, just its v6 address as a candidate. If its 
v4-only and not natted, it provides just its v4. It its v6-only and not 
natted, it provides just its v6.

Because both endpoints are ice-lite, you'll end up with no ICE in this 
case. No stun checks, no nothing. Pretty much as easy as just ANAT alone.

Of course, the great benefit is that if the other side happens to be 
natted, dual-homed or not, you'll get nat traversal working for that 
endpoint. Or if its not natted but has lots of v6 and v4 addresses and 
it wants to figure out connectivity for them, then that'll work too. And 
of course if an endpoint is also possibly natted, it would just use the 
full implementation. So there is a natural transition from multi-homed 
(ice-lite) to multi-homed and natted (ice), rather than having to go 
from ANAT to something totally different (ICE).

ANother benefit is that you would no longer need Require in the SIP 
header, whereas this is required for ANAT. This also smooths the 
deployment of this, since you would avoid a second round trip when 
talking to a non-ICE endpoint.

So, I am convinced even more now that we should deprecate anat, and 
v4/v6 transition doc should recommend ICE and a lite-implementation if 
you are known to have always v4/v6. Time is short till MOnday, and I 
expect no one will see this note till post deadline, but this is trivial 
to add to ICE (I just need to change the rule that says one candidate 
only for ice-lite, to one candidate per address family), and I'd like to 
do so.

-Jonathan R.

Gonzalo Camarillo wrote:

> Hi,
> 
> I agree ICE is useful even in the absence of NATs and that every 
> endpoint should implement it. I also agree that even endpoints using 
> ANAT should use ICE. What we have to analyze is the advantage of using 
> ICE on a single m line versus using ICE on each of the two m lines (one 
> for IPv6 and one for IPv4). That is, it is not ANAT vs. ICE. It is an m 
> line per address type vs. a single m line for everything.
> 
> I believe that having a separate m line per address type is cleaner. 
> However, having separate m lines would keep an IPv6-only host from 
> trying to send data to an IPv4-only host through a NAT-PT. Covering this 
> scenario may justify not using ANAT and using ICE on a single m line 
> instead.
> 
> Cheers,
> 
> Gonzalo
> 
> Jonathan Rosenberg wrote:
> 
>> Here are my thoughts on this.
>>
>> I recall discussing this issue way back when with Gonzalo. We had 
>> agreed that ANAT would be complementary to ICE. ANAT would be used in 
>> cases where you were multihomed with v4 and v6, and not worrying about 
>> NAT traversal per se. ICE added a lot of complexity just to deal with 
>> something as simple as picking the right IP version. Also, ICE had the 
>> problem that it had one address as the primary (in the m/c-line) and 
>> the other candidates were secondary, in candidate lines. We wanted a 
>> solution where both addresses were really equivalently treated.
>>
>> Under these assumptions, you would use ANAT when you had both v4 and 
>> v6 public addresses, but public versions of both. If you needed NAT 
>> traversal, you'd use ICE. If you had both v4 and v6 and needed nat 
>> traversal, you'd use both ANAT and ICE. There'd be an m line for v4, 
>> one for v6. ANAT would select which. Then, under the v4 m-line, you'd 
>> have all of your v4 candidates. Under the v6 m-line, all of your v6. 
>> Thats why the ICE spec talks about using ICE to select between native 
>> v6 and 6to4 addresses, for example.
>>
>> However, a few things have changed since we originally made that 
>> decision. Firstly, we've seen that even in the absence of NAT 
>> traversal, ICE is valuable (passive mode, voice hammer prevention, 
>> keepalive timing control). Furthermore, ICE's design now treats the 
>> m/c-line address as a fallback for non-ICE endpoints. We also now have 
>> an option tag, so you could use ICE like ANAT gets used; with an 
>> option tag so you can do something different if the far end doesn't 
>> support it.
>>
>> Another point is, one of the benefits of ICE over ANAT for selection 
>> of v4 vs. v6 is that, you may run into scenarios where both side have 
>> v6 but they turn out to be unconnected; that is, its two phones both 
>> sitting on v6 networks that are not connected together. I don't know 
>> how common it is to have v6 islands unconnected, but it would not 
>> surprise me if this happens every once in a while.
>>
>> So, technically, at this point I think ICE is probably able to provide 
>> a superset of ANAT. One option is to recommend ANAT for the simplest 
>> case (no NAT traversal, dual-homed clients with public IP), and then 
>> ICE for anything more. THe problem with that is, from an interop 
>> standpoint, ICE implementations would also need to do ANAT and it 
>> would be more complicated. Plus, having ICE support on devices that 
>> aren't interested in nat traversal per se is critical for allowing the 
>> OTHER side to support nat traversal (this is why we've been pushing 
>> passive mode).
>> I also suspect it will generally be confusing to the industry to have 
>> two specifications that are very similar.
>>
>> So, my recommendation would be to have ICE obsolete ANAT when its 
>> published. I don't know if its being used yet at all, which might make 
>> this an issue.
>>
>> Thoughts?
>>
>> -Jonathan R.
>>
>>> Gonzalo Camarillo wrote:
>>>
>>>> Hi,
>>>>
>>>> the current ICE draft seems to tackle IPv4 and IPv6 candidates for the
>>>> same media stream. In the past, we developed ANAT to separate them so
>>>> that a single m line used a single IP version. In particular, the
>>>> SIPPING IPv6 transition document recommends the use of ANAT.
>>>>
>>>> We need to align all these efforts.
>>>
>>>
>>>
>>> Probably sooner rather than later if it has any impact on
>>> the SIPPING IPv6 transition draft, since it has already been WGLCd
>>> and is in the "Publication Requested" state.
>>>
>>> Thanks,
>>>
>>> - vijay
>>
>>
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Mar 2007 00:26:40 -0500

As I started to write this proposal below up into ICE, I found that it 
didn't work. The reason is that when two ice-lite implementations meet, 
they fall back to regular rfc3264 processing, which means they use whats 
in the m/c-line. If I change that to allow usage of one of the 
canidates, we'd also need to do a re-invite to 'fix' the m/c-line to 
match what was selected by ICE, as we normally do. That requires 
choosing a controlling/controlled role, and this is no longer ice-lite, 
but a third modality of implementation. I don't want to do that.

So instead I added a dicsussion on how to use ICE and ANAT together, 
when you'd want ANAT alone, and when you'd want ICE and not ANAT. It 
doesn't make a recommendation on which of those three modes; it just 
gives considerations.

-Jonathan R.

Jonathan Rosenberg wrote:

>> ICE on a single m line versus using ICE on each of the two m lines 
>> (one for IPv6 and one for IPv4). That is, it is not ANAT vs. ICE. It 
>> is an m line per address type vs. a single m line for everything.
>>
>> trying to send data to an IPv4-only host through a NAT-PT. Covering 
>> this scenario may justify not using ANAT and using ICE on a single m 
>> line instead.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>> cases where you were multihomed with v4 and v6, and not worrying 
>>> about NAT traversal per se. ICE added a lot of complexity just to 
>>> deal with something as simple as picking the right IP version. Also, 
>>> ICE had the problem that it had one address as the primary (in the 
>>> m/c-line) and the other candidates were secondary, in candidate 
>>> lines. We wanted a solution where both addresses were really 
>>> equivalently treated.
>>>
>>> m/c-line address as a fallback for non-ICE endpoints. We also now 
>>> have an option tag, so you could use ICE like ANAT gets used; with an 
>>> So, technically, at this point I think ICE is probably able to 
>>> provide a superset of ANAT. One option is to recommend ANAT for the 
>>> simplest case (no NAT traversal, dual-homed clients with public IP), 
>>> and then ICE for anything more. THe problem with that is, from an 
>>> interop standpoint, ICE implementations would also need to do ANAT 
>>> and it would be more complicated. Plus, having ICE support on devices 
>>> that aren't interested in nat traversal per se is critical for 
>>> allowing the OTHER side to support nat traversal (this is why we've 
>>> been pushing passive mode).
>>> published. I don't know if its being used yet at all, which might 
>>> make this an issue.
>>>
>>> Thoughts?
>>>
>>> -Jonathan R.
>>>
>>>> Gonzalo Camarillo wrote:
>>>>
>>>>> Hi,
>>>>>