Subject: [BEHAVE] Question about heuristic discovery and connectivity tests

From: <[email-masked]>
Date: Thu, 12 Jan 2012 09:05:20 +0000

Hi,

The current -04 version of heuristic discovery says in section 3.2 "Connectivity test":
--
   The host MUST NOT perform connectivity test against the IPv4 address
   of the well-known name, but instead use some other destination such
   as host vendor's servers.

   In many scenarios separate connectivity test is not really required
   as an application may just try to connect to the IPv4-only
   destination with synthetic IPv6 address and see if a connection is
   successfully established or not.
--

Dan suggested me to initiate discussions about this in order to improve the section.

The reason why it currently says MUST NOT is to avoid all (and especially excess) traffic towards the IPv4 address(es) used by the "ipv4only.arpa" (to avoid unwanted global traffic). I can clarify that for sure.

However, the question is then whether we should have "connectivity test" section at all and if yes, whether host actually needs to perform separate connectivity test at first place, and if yes, to what destination the connectivity test could be made by the host.

One option could be to state that separate connectivity test SHOULD NOT be done: it should be enough to just try the synthetic IPv6 address whenever one is needed and if connection fails to set up, well, then destination is unreachable. Optionally host might be able to learn that synthetic addresses are systematically failing and hence maybe the prefix discovery has failed..

Another option could be to state that OS/application MAY perform a separate connectivity test, if the OS/application finds that useful and has a destination that is happy to receive connectivity test messages from said OS/application. This destination could be OS/application vendor's dedicated internet connectivity test server, vendor's homepage, OS/application's software update repository or similar. It might also be possible to "bundle" the connectivity test with some other communications OS/application initiates anyway, for example, contact to software update repository through NAT64 *on purpose*, even if the repository would be directly IPv6 reachable.

Any thoughts?

Best regards,

	Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 12 Jan 2012 08:35:07 -0800

On Jan 12, 2012 1:06 AM, <[email-masked]> wrote:
> The reason why it currently says MUST NOT is to avoid all (and especially
excess) traffic towards the IPv4 address(es) used by the "ipv4only.arpa"
(to avoid unwanted global traffic). I can clarify that for sure.
>
> However, the question is then whether we should have "connectivity test"
section at all and if yes, whether host actually needs to perform separate
connectivity test at first place, and if yes, to what destination the
connectivity test could be made by the host.

I do not believe a connectivity check  language is required.  As your
example states, ipv4only.arpa will never respond to a connection, so it
would be unlikely that something is deployed at scale like this since no
connection yields no information.

Fyi. There is beta code of this draft that references ipv4.t-mobile.com.  I
look forward to the advancement of this draft and the official reference
name.

Cb
> One option could be to state that separate connectivity test SHOULD NOT
be done: it should be enough to just try the synthetic IPv6 address
whenever one is needed and if connection fails to set up, well, then
destination is unreachable. Optionally host might be able to learn that
synthetic addresses are systematically failing and hence maybe the prefix
discovery has failed..
>
> Another option could be to state that OS/application MAY perform a
separate connectivity test, if the OS/application finds that useful and has
a destination that is happy to receive connectivity test messages from said
OS/application. This destination could be OS/application vendor's dedicated
internet connectivity test server, vendor's homepage, OS/application's
software update repository or similar. It might also be possible to
"bundle" the connectivity test with some other communications
OS/application initiates anyway, for example, contact to software update
repository through NAT64 *on purpose*, even if the repository would be
directly IPv6 reachable.
>
> Any thoughts?
>
> Best regards,
>
>        Teemu
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave