mmusic - ICE draft-16: review and guidance for IPv6/IPv4 implementations

["Jean-Francois Mule" <jf.mule@cablelabs.com>]

   The current draft for ICE is:
	http://tools.ietf.org/html/draft-ietf-mmusic-ice-16

   As some of you are aware, the mmusic wg has completed an extended
WGLC on ICE (Interactive Connectivity Establishment). ICE is a protocol
designed to "guarantee" IP connectivity for media streams between hosts
that use an offer/answer mechanism such as the one used by SIP
implementations today (RFC 3264 - offer/answer in SDP). 
Draft-16 integrates WGLC comments, especially on the use of ICE by
multi-homed and dual-stack hosts. The assumption is that ICE will be
used by agents supporting dual-stack operations. ICE is therefore
intended to deprecate RFC 4091 (4091 provided a mechanism for an agent
to indicate it supports both IPv6 and IPv4 for a media stream - see
section 13 of ICE, or below for details).

   We'd appreciate if IPv6 folks could review the latest draft in the
context of IPv6-capable hosts (IPv6-only, dual-stack IPv6/IPv4) and
provide comments, any additional guidance on ICE implementation/usage by
IPv6 hosts.

   There is also one particular item for which some input for the v6ops
wg would be valuable: it's re: the limitations of dual-stack ICE
implementations (so called ICE Lite).

--- Some context
At the last IETF meeting, it was agreed to that ICE will deprecate ANAT
(RFC4091); see for details. ANAT defines SDP extensions for expressing
alternative network addresses for media streams (and was intended to be
used by IPv6/IPv4 hosts to offer alternative addresses for IPv6/IPv4).

It is therefore expected that the use of ICE will become the prevalent
mechanism for dual-stack IPv6/IPv4 implementations to determine which
candidate addresses to use for source & destination address selection
for media streams.
Both RFC 3484 and ICE are complementary in the sense that ICE is an
application level protocol trying to figure out connectivity (the ICE
algorithm can take address priorities and local preferences into
account) -- as hinted at in 3484. See section 4.2 of ICE draft-16 for
how ICE relies on 3484's precedence calue for IP addresses to prioritize
transport address candidates of IPv6 hosts.

In our wg discussions, folks have proposed to use ICE-lite rather than
full ICE for dual-stack implementations (ICE Lite is simplified version
of ICE without "end-to-end" connectivity checks, see ice-16 for
details).


--- What is the Problem?
Based on some reading of several v6ops threads and drafts, it seems that
RFC 3484 has shortcomings and that, in the problematic cases, the use of
Full ICE with connectivity checks can actually help achieve and
guarantee end-to-end connectivity.

(
some v6ops references are:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-01
but also
http://tools.ietf.org/html/draft-arifumi-v6ops-addr-select-ps-01
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03
http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg01072.html
).

This is why some input from the v6ops group would be appreciated. Should
ICE recommend Full ICE in some cases of IPv6 implementations/all the
never or leave it as-is? 

1) Thoughts?

2) Should there be some text summarizing limitations and giving some
guidance for when to use full ICE [with connectivity checks], something
like:
"Due to some problematic cases identified in
[ID.draft-ietf-v6ops-addr-select-req-01] where the use of RFC 3484 may
result in source/destination addresses with connectivity issues, ICE
implementations in IPv6/IPv4 hosts SHOULD implement full ICE and perform
connectivity checks as described in ..."

==> in other words, given some RFC3484 problematic cases, should ICE
insist in the use of connectivity checks for IPv6 hosts. Is this SHOULD
too strong? Not strong enough? Any other txt proposal?


Sorry for the long note. Comments are appreciated.

Jean-Francois Mule.
jfm@cablelabs.com