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

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 2 Jul 2007 08:17:51 -0600

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.
[email-masked]

---

From: [email-masked]
Date: Tue, 03 Jul 2007 05:51:45 -0600

I have one very serious concern about this draft and the underlaying 
supposition as shown in the full title:
Interactive Connectivity Establishment (ICE): A Protocol for Network Address 
Translator (NAT) Traversal for Offer/Answer Protocols 

As explained in RFC4864 -  Local Network Protection for IPv6 NAT is not to 
be encouraged, and has been removed from IPv6 intentionally. Thus your 
looking at the subset of IPv4 only or Ipv6 to IPv4 network considerations 
only. So you probably should read and reference this RFC. 

This being said this list has had some conversations about how to make just 
what you are talking about possible for the application layer. 

I suggest that you look at the thread common issues in BEHAVE and V6OPS 
(http://psg.com/lists/v6ops/v6ops.2007/msg00254.html) for some of the items 
that were brought up as they seem to directly relate to your draft. 

Eric

draft-ietf-mmusic-ice-16