Subject: new things that ISOC could do: collect data on breakage

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 11:42:52 -0500

{Many people expressed various amounts of outrage privately that I should
suggest that ISOC do any kind of conformance testing.}

So, let me suggest something slightly less which just occured to me from a
6man thread which I include below.  Please read Brian's imagined letter in
quotes, and think about how "corporate travel plan" can get the data that it
needs to make such a decision.

ipv6-test.com actually does a pretty good job of a lot of the testing I have
in mind for travellers at hotels.  And they collect data about which
ISP/country is involved: http://ipv6-test.com/stats/

What's missing is the ability to collect the information in a useful way back
to the people/organizations that paid for the hotel such that they have
enough data.   i.e. a way to volunteer non-anonymous statistics to a private
collection.

And ipv6-test.com only works if you minimally can get online at least a bit,
although since it's javascript maybe a file:// URL version could be created.

This is something that ISOC could do:  help collect measurements of problems.
I know that people and places like kc@caida and Geoff Houston do a lot of
systematic testing of some things, but not random stuff.

Brian E Carpenter <[email-masked]> wrote:
    >> I like to refer back to Occam’s Razor e2e v6 rather than transition Rube
    >> Goldberg

    > I think we all agree on the long-term fix. The issue seems to be how
    > we can best (or least badly) deal with legacy hosts and apps that
    > will be out there for years, generating help desk calls or lost
    > business.

    > "Hi! Your hotel group has been removed from our corporate travel
    > plan because none of our employees can connect to our corporate VPN
    > from your hotels any more, as confirmed by your WiFi supplier."

So, I've been hoping that between sunset4, bahave, capport and ipsecme, that
we'd get some set of tests that could be run on a laptop/smartphone which
would characterize the nature of the breakage better.

ipv6-test.com actually gets 60% of the way there, but when the breakage
occurs, we do not really have a place to report/collate the information.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 23 Nov 2017 18:46:53 +0100

Well ….

This is somehow related to this work:

https://datatracker.ietf.org/doc/draft-palet-v6ops-he-reporting/

I’m just trying to figure out how to make easy an automatic reporting to a common system among ISPs, while avoiding possible privacy issues.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Michael Richardson <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 23 de noviembre de 2017, 17:43
Para: <[email-masked]>
Asunto: new things that ISOC could do: collect data on breakage

    

    

    

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 16:12:02 -0500

> https://datatracker.ietf.org/doc/draft-palet-v6ops-he-reporting/

   In order to simplify the reporting of the HE failures, syslog
   ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the
   default port (514) with IPv6-only.

btw, TCP port 514 is "rlogin" and both UDP and TCP are often blocked because
of lazyness....  And syslog is often blocked intentionally.
I suggest that the MILE work might provide a better structure for that.

When you write "operator" is that the operator of the web site, or the
operator of the network you are in?

Given that most hotel networks feature absentee landlords, this is
why I want to involve ISOC.