Subject: Re: [v6ops] I-D Action:draft-wing-v6ops-happy-eyeballs-ipv6-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2010 14:48:19 +1300

Hi,

> 3.  Problem Statement
...
>    As discussed in more detail in Section 3.2, IPv6 connectivity is
>    sometimes broken entirely or slower than native IPv4 connectivity.

Could you add something like:

Later in the transition process, it is likely that the exact opposite of
this will apply. A strategy is needed that deals equally well with both of
these situations.

> 4.1.  IPv6
...
>    The first thread that succeeds returns the completed connection to
>    the parent code and aborts the other thread (Section 4.2.2).

Is there a race condition here?

> 4.2.4.  Determining Address Type
> 
>    [[[ IS THIS SECTION NECESSARY ??

I don't see why.

> 4.2.5.  Debugging and Troubleshooting
> 
>    This mechanism is aimed to help the user experience in case of
>    connectivity problems.  However, this precise reason also makes it
>    tougher to use these applications as a means of the verification that
>    the problems are fixed.  To assist in that regard, the applications
>    implementing the proposal in this document SHOULD also provide a
>    mechanism to temporarily use only one address family.

Could I suggest that the last sentence should be

 To assist in that regard, the applications
 implementing the proposal in this document MUST also provide a
 configurable mechanism to use only one address family if both
 are available.

I think it really is a MUST for trouble-shooting, and the key
point isn't that it's temporary but that it can be switched on
and off.

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Oct 2010 12:26:15 +0200

Hi, Brian, Dan,

This proposal is IMHO very useful.
I support that it can become a WG document.

> this will apply. A strategy is needed that deals equally well with both of

Agreed.
(The problem is also similar to that which already exists in IPv4 when the DNS returns several A records.)

Also, sec 3 says:   
   "Reasons for such failure include no connection to the IPv6 Internet,
   broken 6to4 or Teredo tunnels, and broken IPv6 peering."

It could usefully be clarified that these failures have different natures, e.g. with:
"Reasons for such failure include missing paths between some 6to4 addresses and native IPv6 addresses, incompatible NAT types between some Teredo addresses, or temporary breakage of IPv6 paths."

Note that a hosts that has an IPv6 address other than 6to4 should have a both-way connection to the IPv6 Internet unless something is temporarily broken. 

> Is there a race condition here?

Not that I see.
The connection initiator makes the decision in view of what *he sees* as the first one to succeed.

>>   [[[ IS THIS SECTION NECESSARY ??

The subject is worth looking at, IMHO, but seems out of scope for this draft which should stand for itself.

> point isn't that it's temporary but that it can be switched on

SHOULD seems good enough to me (equivalent to a MUST unless you find some good raison against it), but MUST is OK too.

Regards,
RD

---

From: Scott Brim <[email-masked]>
Date: Wed, 27 Oct 2010 10:36:31 -0400

> point isn't that it's temporary but that it can be switched on

The essence of this section is that there should be some way to bypass
the nice features of happy eyeballs in order to be able to probe what's
really going on in the network at the app level.

I agree that "temporary" isn't the key point, and would remove that.
However, I don't believe that _all_ applications _must_ implement a
bypass mechanism, as Brian suggests.  The only apps that must implement
it are the ones that need it: debugging tools, for instance.  You don't
need to use a web browser in order to do a traceroute.  So, since this
choice is on a per-application basis, I suggest

  To assist in that regard, environments implementing the proposal
  in this document MUST provide a mechanism by which an application MAY
  be able use only one particular address family.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2010 11:36:27 +1300

Hi Scott,

>   be able use only one particular address family.

Well, I am not too bothered about this, but let me say that I have
many times had occasion to flip the state of network.dns.disableIPv6
in Firefox, independently of doing traceroute.

   Brian