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

From: "Elwell, John" <[email-masked]>
Date: Sat, 07 Apr 2007 20:53:47 +0100

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 05 April 2007 13:22
> To: Elwell, John
> Cc: [email-masked]
> Subject: 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. 
[JRE] I a sense, yes. However, a syntactic transformation with a couple of
benefits. First, it should be backwards compatible with plain vanilla IPv4
implementations. Remember ANAT uses two m-lines and requires an option tag
in the Require header field to ensure the UAS understands. This leads to
some nasty interactions with 3PCC. The ICE syntax neatly gets around this
problem. The second benefit is that this is a step on the path towards full
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. 
[JRE] My proposal is to mandate that regular ice endpoints support
micro-lite.

> 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.
[JRE] Indeed, and that is because micro-lite would be employed in non-NAT
environments (or SBC environments) where IPv4/IPv6 transition is needed.

> 
> -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.
> > 
> > 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
> > 
> 
> -- 
> 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, 09 Apr 2007 09:05:57 -0400

inline.

> problem. The second benefit is that this is a step on the path towards full

Not really. There is nothing here that resembles ICE except a piece of 
syntax.

> [JRE] My proposal is to mandate that regular ice endpoints support

Which, if that endpoint is behind a NAT, doesn't help them one drop.

With ice-lite as defined today, this is not so. With ice-lite, the agent 
on the public network that is doing ice-lite, is still allowing its peer 
to be full ICE, and for that peer to be behind a NAT, and get the full 
benefits of ICE. With your proposal, the endpoint behind a NAT would be 
out of luck entirely.

So, with your 'ice-micro-lite', basically both agents do ice-micro-lite, 
or nothing.

So, lets not kid ourselves. What you are proposing is to undo the 
consensus decision at IETF 68, and instead, define something that is 
basically the same as ANAT, but uses the ICE syntax instead. I am 
opposed to that. I understand that ICE adds complexity, there is no 
dispute that it is more complex than ANAT. However, the view was that 
this complexity was worth the benefits.

> environments (or SBC environments) where IPv4/IPv6 transition is needed.

Which only underscores the point - this is not ICE, this is something 
entirely orthogonal. Its ANAT with ICE syntax.

-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: Mon, 9 Apr 2007 20:00:55 -0500

> > [JRE] Indeed, and that is because micro-lite would be employed in 
> > non-NAT environments (or SBC environments) where IPv4/IPv6 
> transition is needed.
> 
> Which only underscores the point - this is not ICE, this is 
> something entirely orthogonal. Its ANAT with ICE syntax.

Or you could say it's ICE with a possibility of bypassing the
connectivity check
WHEN APPROPRIATE.

In my mind, BOTH sides would have to explicitly indicate that they wish
to use 
ice-microlite for the bypass to happen.

If either end is behind a NAT, it will therefore end-up using full-ice
because it
will not include the microlite flag.

In fact, wouldn't this be useful even for ice-lite (not microlite, just
lite), where
if both PSTN gateways are on the public internet, they know right away
they can skip the
connectivity check?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Apr 2007 09:24:17 -0400

inline.

> will not include the microlite flag.

No, it won't. The problem is that if the offeror sends 'ice-micro-lite' 
and the answerer is behind a NAT and wants full ICE, the answerer is out 
of luck. ICE-lite has this really important property that, if one side 
is ice-lite, and the other is full, the full side still gets the entire 
complete benefits of ICE for NAT traversal.

> if both PSTN gateways are on the public internet, they know right away

That already happens. If both agents are ICE lite, there are no 
connectivity checks that get utilized.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Apr 2007 10:43:21 -0500

> > because it will not include the microlite flag.
> 
> and the answerer is behind a NAT and wants full ICE, the 
> answerer is out of luck. ICE-lite has this really important 
> property that, if one side is ice-lite, and the other is 
> full, the full side still gets the entire complete benefits 
> of ICE for NAT traversal.

Wouldn't that work here then? Wouldn't we want the "full side"
to get the benefits here, i.e., the ice-micro-lite MUST respond
to connectivity checks?

> connectivity checks that get utilized.

Ok, good.

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 10 Apr 2007 18:52:36 -0500

Jonathan, please see below. I'm not sure your response meshes with
what's in the draft.

Regards,
Brian

> Sent: Tuesday, April 10, 2007 8:24 AM
> To: Audet, Francois (SC100:3055)
> Cc: Elwell, John; [email-masked]
> Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> inline.
> 
> Francois Audet wrote:
> 
> >  
> > 
> > 
> something 
> > connectivity check WHEN APPROPRIATE.
> > 
> > In my mind, BOTH sides would have to explicitly indicate that they 
> > wish to use ice-microlite for the bypass to happen.
> > 

Jonathan, I don't understand what you mean by if both agents are ICE
lite, there are no connectivity checks.

Looking at section 5 and 5.1 of ICE-15, I see the following text:

---
5.  Receiving the Initial Offer

   When an agent receives an initial offer, it will check if the offeror
   supports sufficient ICE functionality to proceed (i.e., if both
   offeror and answerer are lite implementations, ICE cannot proceed),
   determine its own role, gather candidates, prioritize them, choose
   default candidates, encode and send an answer, and for full
   implementations, form the check lists and begin connectivity checks.

5.1.  Verifying ICE Support

   The answerer will proceed with the ICE procedures defined in this
   specification if the following are all true:

   o  For each media stream, the default destination for at least one
      component of the media stream appears in a candidate attribute.
      For example, in the case of RTP, the IP address and port in the c
      and m line, respectively, appears in a candidate attribute, or the
      value in the rtcp attribute appears in a candidate attribute.

   o  The offer omitted an a=ice-lite attribute or the answerer is a
      full implementation.  In other words, if both agents are lite
      implementations, the agent does not proceed with ICE.

   If any of these conditions are not met, the agent MUST process the
   SDP based on normal RFC 3264 procedures, without using any of the ICE
   mechanisms described in the remainder of this specification with the
   following exceptions:

   1.  The agent MUST follow the rules of Section 10, which describe
       keepalive procedures for all agents.

   2.  If the agent is not proceeding with ICE because there were
       a=candidate attributes, but none that matched the default
       destination of the media stream, the agent MUST include an a=ice-
       mismatch attribute in its answer.
---

I read this as saying that if both the offerer and answerer specify
ice-lite, then you drop back to 3264, meaning that there's not just no
connectivity checks, there's no candidate lines either because there's
no ICE.

Regards,
Brian

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Apr 2007 19:11:13 -0500

> connectivity checks that get utilized.

Jonathan,

I'm reading your section 5 of ICE-15, and I think
we have almost what is requested. We probably don't even need
anything beyond ice-lite.

A sends offer to B. It is not behind a NAT, but it is dual
stack and supports IPv4 and IPv6, so it has:

Offer:

	m=IPv4                  <- Assumption is that IPv4 is more
likely to succeed than IPv6
	candidate 1=IPv6
	candidate 2=IPv4
	a=ice-lite

B receives the offer, it is also dual stack and NOT behind a NAT.

It sends an answer:

	m=IPv4
	candidate 1=IPv6
	candidate 2=IPv4
	a=ice-lite

According to your section 5 it would result in having "NO CONNECTIVITY
CHECK".

(PS: your wording says "ICE cannot proceed", which I think is innacurate
since 
the candidates have already been sent, so I think you need to clarify
that it means
"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 XXXX procedures (the selection thing: I don't
have the number).

One easy way to do this is to have B responding 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

And B would just use the candidate 1=IPv6 from the offer anyways to send
media.

I think this solves the problem, no?

Isn't this trivial?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 09:45:13 -0400

Francois,

I have considered this issue, and I have a proposal which I believe works.

I think the following are important properties of a solution here:

1. it not be yet another mode; it should be ICE lite or minor orthogonal 
behavior or something

2. absolutely, positively, MUST MUST MUST allow nat traversal for a peer 
that is full. This was our fundamental requirement when designing 
ICE-lite. Anything else and our result is NOT ICE.

3. be much simpler than ICE-full for dual-stack endpoints that are not 
natted

4. maintain the property that the final m/c-line reflects what is really 
used

So, your proposal below is not bad, but fails on requirement 4. I 
believe we still need a 'fix-up' reinvite if the finally selected pair 
doesn't match the m/c-line.

So, here is my suggested variant on your proposal which meets all four.

We enhance ICE-lite a bit, so that it works for dual-stack hosts that 
are not natted or firewalled. As you suggested, when two ICE-lite 
endpoints meet, we don't say that we proceed as if there was no ICE. We 
do proceed. The answerer will send back its candidates (one v4 and a few 
v6), with the a=ice-lite flag. Now, neither side will send checks. 
However, we will do role-selection. Offerer is controller. The 
controller, being ICE-lite, will run RFC3484 to select the IP address 
pairs, rather than running checks to do so. This will be a totally 
static step. Once it selects, the controller sends a re-INVITE or update 
with the fix-up in the m/c-line, and includes only the candidate for its 
selected IP address. It also includes a=remote-candidates telling the 
other side which IP address/port to use.

As for media cut-through, the answerer (as controlled node) can run 
rfc3484 also, pick what it thinks is the winner, and send immediately. 
If it turns out that the controller used a variation on rfc3484 or 
something, and picked a different address, the controlled agent will 
find out when the re-invite comes.

So, what this means is, ice-lite gets a little more complicated. Its not 
any more complicated than it is today if you have a single IP. If you 
are dual-stack, the complexity would be current ICE-lite, plus the 
ability to send the fix-up re-INVITE with a=remote-candidates.

This does mean that a dual-stack host that is not natted would need to 
be able to respond to STUN requests. This would happen when that 
dual-stack host calls a full implementation. I think this is absolutely 
essential and with fight with great vigor any attempts to have a 
different mode of ICE which does not require even responding to STUN 
checks. Big big mistake IMHO.

Now, what about this role conflict bit? Well, per my other note, I 
actually only have cases where both sides are controlling. In that case, 
both would run RFC3484, both would re-INVITE. We'd get glare, but it 
would be resolved by standard RFC3261 techniques. So, it works. Not 
optimally, since we end up with two re-invites where one would do. But 
it still works.

I have glanced through the text, and believe this change is actually not 
hard to make.

Note further that, even with this change, ice-13 and onwards would still 
be compatible with ice-16 (if anyone cares).

Does this work for people?

-Jonathan R.

Francois Audet wrote:

>  
> 
>>>In fact, wouldn't this be useful even for ice-lite (not 
>>
>>microlite, just
>>
>>>lite), where
>>>if both PSTN gateways are on the public internet, they know 
>>
>>right away
>>
>>>they can skip the
>>>connectivity check?
>>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Apr 2007 11:18:36 -0500

Hi Jonathan,

I'm 100% happy with what you are proposing here (including your 4
requirements).

In fact, that's exactly what I was thinking too: i.e., that we'd need to
have the second offer/answer to correct the m lines, and that we'd 
need to use the RFC 3484 rules. Even the fact that it's not a new mode,
but it
IS ice-lite (with a minor fix-up) is covered in that posting.

In fact, I had re-submitted formally the email you quote as WGLC
comments on 
4/18
(http://www1.ietf.org/mail-archive/web/mmusic/current/msg05592.html),
adding 
a paragraph at the end stating this, as well as a reference to RFC 3484.

So, basically we were thinking exactly the same thing. Good.

This completely addresses my WGLC comment. 

I also believe that ICE now truely, absolutely, removes any need for
ANAT. This
solution will be very clean, efficient and simple for non-NATed devices.

> Sent: Thursday, April 26, 2007 06:45
> 1. it not be yet another mode; it should be ICE lite or minor 
> orthogonal behavior or something
> 
> 2. absolutely, positively, MUST MUST MUST allow nat traversal 
> for a peer that is full. This was our fundamental requirement 
> when designing ICE-lite. Anything else and our result is NOT ICE.
> 
> 3. be much simpler than ICE-full for dual-stack endpoints 
> that are not natted
> 
> 4. maintain the property that the final m/c-line reflects 
> what is really used
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Apr 2007 17:38:55 +0100

Jonathan,

Yes, I believe this would be beneficial. Thanks.

John 

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 26 April 2007 17:19
> To: Jonathan Rosenberg
> Cc: Elwell, John; [email-masked]; John Rutledge
> Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> Hi Jonathan,
>

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 26 Apr 2007 12:26:16 -0500

Hi Jonathan,

This works for me as well, and I think addresses the exact pattern I was
looking for from the ANAT deprecation discussion. 

Looking forward to the updated document.

Regards,
Brian 

> From: Audet, Francois (SC100:3055) 
> Sent: Thursday, April 26, 2007 11:19 AM
> To: Jonathan Rosenberg
> Cc: Elwell, John; [email-masked]; Rutledge, John (NGD:X260); 
> Stucker, Brian (RICH1:AR00)
> I'm 100% happy with what you are proposing here (including 
> your 4 requirements).
> 
> In fact, that's exactly what I was thinking too: i.e., that 
> we'd need to have the second offer/answer to correct the m 
> lines, and that we'd need to use the RFC 3484 rules. Even the 
> fact that it's not a new mode, but it IS ice-lite (with a 
> minor fix-up) is covered in that posting.
> 
> In fact, I had re-submitted formally the email you quote as 
> WGLC comments on
> 4/18 
> (http://www1.ietf.org/mail-archive/web/mmusic/current/msg05592
.html), adding a paragraph at the end stating this, as well as a >
reference to RFC 3484.
> I also believe that ICE now truely, absolutely, removes any 
> need for ANAT. This solution will be very clean, efficient 
> and simple for non-NATed devices.
> 
> > 2. absolutely, positively, MUST MUST MUST allow nat traversal for a 
> > peer that is full. This was our fundamental requirement 
> when designing 
> that are not 
> > 4. maintain the property that the final m/c-line reflects what is 
> > really used
> > 
> > 
> > endpoints meet, we don't say that we proceed as if there 
> was no ICE. 
> > We do proceed. The answerer will send back its candidates (one
> > v4 and a few
> > static step. Once it selects, the controller sends a re-INVITE or 
> > update with the fix-up in the m/c-line, and includes only the 
> > candidate for its selected IP address. It also includes 
> > a=remote-candidates telling the other side which IP address/port to 
> > use.
> > 
> > So, what this means is, ice-lite gets a little more 
> complicated. Its 
> > not any more complicated than it is today if you have a 
> single IP. If 
> > you are dual-stack, the complexity would be current 
> ICE-lite, plus the 
> > dual-stack host calls a full implementation. I think this is 
> > absolutely essential and with fight with great vigor any 
> attempts to 
> > have a different mode of ICE which does not require even 
> responding to 
> > STUN checks. Big big mistake IMHO.
> > 
> > actually only have cases where both sides are controlling. In that 
> > case, both would run RFC3484, both would re-INVITE. We'd get glare, 
> > but it would be resolved by standard RFC3261 techniques. 
> So, it works. 
> > Not optimally, since we end up with two re-invites where 
> one would do. 
> > But it still works.
> > 
> > I have glanced through the text, and believe this change is 
> actually 
> > not hard to make.
> > 
> > Note further that, even with this change, ice-13 and onwards would 
> > still be compatible with ice-16 (if anyone cares).
> > 
> > > I'm reading your section 5 of ICE-15, and I think we have almost 
> > > what is requested. We probably don't even need anything beyond 
> > > ice-lite.
> > > 
> > > A sends offer to B. It is not behind a NAT, but it is 
> dual stack and 
> > > supports IPv4 and IPv6, so it has:
> > > 
> > > Offer:
> > > 
> > > selected instead of the IPv6 (i.e., the m line).
> > >

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 27 Apr 2007 02:51:36 -0600

Hi all,

> orthogonal behavior or something
I agree that we should not have more profiles of ICE (no
micro/ultra-lite version). But let's not think that ICE-lite is it, even
the proposed solution below.
I think there is value in connectivity checks given the known
shortcomings of 3484 and the fact that ICE provides an application-level
selection mechanism which by essence should guarantee "Internet
*Connectivity Establishment*".

> 3. be much simpler than ICE-full for dual-stack endpoints that are not
After reading a few drafts and archives in the v6ops group (old and
current), there are known limitations of 3484 and many proposals on how
the address selection mechanism should be updated or improved to
ultimately guarantee connectivity. This goes beyond the NAT cases, and
it is sometimes applicable to multi-homed v6 nodes, etc.

References:
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03
http://tools.ietf.org/html/draft-arifumi-v6ops-addr-select-ps-01
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-01.
txt
http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg01072.html

When I read your proposal trying to connect the dots between this thread
and the above v6ops references (looking at it as someone deciding what
to implement in a dual-stack host given the current state of the art),
it seems to me that with ICE, we have a mechanism to resolve those
potential 3484 issues by doing connectivity checks. Yet, we're about to
say, no, just do ICE-lite+ and no connectivity checks.

> ability to send the fix-up re-INVITE with a=remote-candidates.

And why not add connectivity checks too given the above references?
At a minimum, there should be a strong statement made in the draft that
dual-stack hosts using 3484 SHOULD consider full implementation of ICE.

> be able to respond to STUN requests. This would happen when that
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This begs the question of why not bite the bullet and mandate
connectivity checks in this case?
What is happening here is folks trying to lower the bar on the level of
requirements for ICE by putting ICE-lite, yet some others raising it to
cover more use cases.

I think the draft must contain a warning in the ICE-lite definition that
ICE-lite does not guarantee connectivity establishment.

> absolutely
> case,
> still

This scenario continues to pose the question of what is ICE-lite useful
for without connectivity checks and what guidance is provided to
implementers.

Jean-Francois.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Apr 2007 12:35:51 -0400

inline.

> *Connectivity Establishment*".

Agree. THis is true generally; the doc has warnings about ICE-lite.

> say, no, just do ICE-lite+ and no connectivity checks.

No, I'm not saying that. I'm saying, if you think you can deal with the 
following limitations A,B, and C, then use ice-lite. Otherwise, use 
full, and full is always better.

In the case of dual-stack, I don't follow v6ops, so if you could provide 
some text that I could include in ICE, summarizing limitations, giving 
some guidance for when to use full, that would be great.

> dual-stack hosts using 3484 SHOULD consider full implementation of ICE.

I think that this is true in general, not just for dual stack. The 
introduction, section 2.7, says this:

It is important to note that the lite implementation was added to
    this specification to provide a stepping stone to full
    implementation.  Even for devices that are always connected to the
    public Internet, a full implementation is preferable if achievable.

and later in the appendix:

  It is important to note that the lite implementation was added to
    this specification to provide a stepping stone to full
    implementation.  Even for devices that are always connected to the
    public Internet, a full implementation is preferable if achievable.
    A full implementation will reduce call setup times.  Full
    implementations also obtain the security benefits of ICE unrelated to
    NAT traversal; in particular, the voice hammer attack described in
    Section 17 is prevented only for full implementations, not lite.
    Finally, it is often the case that a device which finds itself with a
    public address today will be placed in a network tomorrow where it
    will be behind a NAT.  It is difficult to definitively know, over the
    lifetime of a device or product, that it will always be used on the
    public Internet.  Full implementation provides assurance that
    communications will always work.

so, it would be appropriate to add more here for dual-stack.

>>be able to respond to STUN requests. This would happen when that

If it were just as easy as 'just send them too', I would agree. But its 
not. IMHO the hard part of ICE is all the state machinery. Its the check 
lists, the timers, the frozen algorithm, sending updates, computing 
remote-candidate, dealing with priority and peer reflexive candidates, 
all of that. All of which are necessary when you are sending checks too.

So I think the bar for ice-lite is quite a bit lower than full ICE.

> ICE-lite does not guarantee connectivity establishment.

OK.

> for without connectivity checks and what guidance is provided to

Please take a look at the intro and appendix A, and see if you feel more 
needs to be said.

Thanks,
Jonathan R.