New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
Dear colleagues, Collaborative efforts in the BCOP TF have led to the following document, detailing how to troubleshoot IPv6 connectivity. The author(s) have asked us to forward this to the IPv6 Working Group for review, with the intend of publishing this as RIPE Document. To clarify the procedure, any document, when there is consensus within the working group can receive a number and be published as part of the RIPE Document series. As it does not specify any RIPE policy or changes existing policy, we are comfortable in not invoking the formal PDP for this. Please review this document and leave any comments regarding the contents on this list. Also we would like to receive some feedback wether you think this document should be published as a RIPE Document. Please leave your initial comments before Monday 7 November COB, we will carve out some time in the RIPE 69 agenda to talk about this and to decide on the workflow. Regards, Marco Hogewoning co-chair of the IPv6 Working Group
At Sun, 26 Oct 2014 12:21:35 +0100, Marco Hogewoning wrote:
6. Explanation of Help Desk Codes on {\field{\*\fldinst{HYPERLINK "http://test.test-ipv6.om"}}{\fldrslt \ul http://isp.test-ipv6.com}} \
Target of hyperlink is broken. Why impose RTF on the proof-reader instead of markdown or PDF? ATB Niall
6. Explanation of Help Desk Codes on {\field{\*\fldinst{HYPERLINK "http://test.test-ipv6.om"}}{\fldrslt \ul http://isp.test-ipv6.com}} \
Target of hyperlink is broken.
Will get checked/fixed when going to final markup...
Why impose RTF on the proof-reader instead of markdown or PDF?
Choosing one evil over the other, preferably it would have been plain text or it a more final version in PDF. The first option would have lost too much of the structure and the second option would have required additional resources which might be considered wasteful given this is a very early draft. Besides that, also not everybody is happy with receiving pdf. Sorry, this is one where it is near impossible to get right for everybody. Hope the format we picked allows for people to review without to much effort. I think most mail readers will he able to make something from RTF without the aid of additional software or plugins. Marco
At Sun, 26 Oct 2014 14:57:25 +0100, Marco Hogewoning wrote:
Sorry, this is one where it is near impossible to get right for everybody.
Only if you avoid the opportunity to send alternatively formatted attachments. Surely that's not hard? For me, RTF is utterly abominable. I'ld even prefer DOCX! ATB Niall
At Sun, 26 Oct 2014 12:21:35 +0100, Marco Hogewoning wrote:
[1 <text/plain; us-ascii (quoted-printable)>] Dear colleagues,
Collaborative efforts in the BCOP TF have led to the following document, detailing how to troubleshoot IPv6 connectivity.
The author(s) have asked us to forward this to the IPv6 Working Group for review, with the intend of publishing this as RIPE Document.
Apologies if this is premature comment. In order to avoid misleading diagnostics, some of the test targets need actually to be made available before the document is released. For example: dhcp-179(niall)7: curl -v http://ipv6.test-ipv6.ceengine.eu/images-nc/knob_valid_green.png * Adding handle: conn: 0x7f84e4004400 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7f84e4004400) send_pipe: 1, recv_pipe: 0 * About to connect() to ipv6.test-ipv6.ceengine.eu port 80 (#0) * Trying 2001:b30:1::144... * Failed connect to ipv6.test-ipv6.ceengine.eu:80; Connection refused * Closing connection 0 curl: (7) Failed connect to ipv6.test-ipv6.ceengine.eu:80; Connection refused dhcp-179(niall)8: ping6 -c5 ipv6.test-ipv6.ceengine.eu PING6(56=40+8+8 bytes) 2001:770:13f:1:ec12:82f2:cf03:1149 --> 2001:b30:1::144 16 bytes from 2001:b30:1::144, icmp_seq=0 hlim=51 time=72.447 ms 16 bytes from 2001:b30:1::144, icmp_seq=1 hlim=51 time=77.818 ms 16 bytes from 2001:b30:1::144, icmp_seq=2 hlim=51 time=70.829 ms 16 bytes from 2001:b30:1::144, icmp_seq=3 hlim=51 time=70.720 ms 16 bytes from 2001:b30:1::144, icmp_seq=4 hlim=51 time=106.215 ms --- aaaa.test-ipv6.ceengine.eu ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 70.720/79.606/106.215/13.553 ms dhcp-179(niall)9: ATB Niall
On Sunday, October 26, 2014, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
* Failed connect to ipv6.test-ipv6.ceengine.eu:80; Connection refused
As soon as I can get near a real computer I'll do a fresh audit and disable/contact broken sites. I'll also put more thought into how to export the data needed to a nagios plugin to catch issues quicker. -- Jason Fesler, email/jabber <jfesler@gigo.com> resume: http://jfesler.com "Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life."
At Sun, 26 Oct 2014 08:35:17 -0700, Jason Fesler wrote:
On Sunday, October 26, 2014, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
* Failed connect to ipv6.test-ipv6.ceengine.eu:80; Connection refused
As soon as I can get near a real computer I'll do a fresh audit and disable/contact broken sites. I'll also put more thought into how to export the data needed to a nagios plugin to catch issues quicker.
Great! Thanks for the speedy response, Jason. Thinking a bit more, I have the idea that some more thought is needed about how the script running in the browser interprets failure to retrieve any of the target resources. In the case mentioned, it looks as if application error HTTP 404 is being interpreted as indicating IPv6 network target unreachable. Isn't this a layering misinterpretation? ATB Niall
On Sun, Oct 26, 2014 at 10:52 AM, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
In the case mentioned, it looks as if application error HTTP 404 is being interpreted as indicating IPv6 network target unreachable. Isn't this a layering misinterpretation?
Yes. But I have limits on what I can do in JavaScript, without invoking browser specific or even operating system specific code, or depending on plugins. I can (as far as I know) only detect success, failure, and timeout. Above all, I want the site to operate purely on simple clean javascript that works on any popular browser, and ideally, even the unpopular javascript-enabled browsers. FWIW: I always check IPv4 as a control measure. I only complain when IPv6 fails but IPv4 worked. This catches the case of apache httpd being down; it catches power down; it doesn't catch more subtle problems. When the control is down, I discount it from the list of failures (grey instead of red; and the ISP test in particular stops counting it). Not perfect; but if you can help me improve on this in a way that keeps my goal of simple javascript, I'm very much interested in your ideas. In some cases, it may be as simple as expertise (since JavaScript is not my "native tongue", so to speak). Thanks for the feedback! And thanks for taking the time to read the document. A lot of people have put a lot of time into that document already. I'm hoping ultimately the community finds the document (and the site) useful. -- Jason Fesler, email/jabber <jfesler@gigo.com> resume: http://jfesler.com "Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life."
At Sun, 26 Oct 2014 11:40:31 -0700, Jason Fesler wrote:
On Sun, Oct 26, 2014 at 10:52 AM, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
In the case mentioned, it looks as if application error HTTP 404 is being interpreted as indicating IPv6 network target unreachable. Isn't this a layering misinterpretation?
Yes. But I have limits on what I can do in JavaScript, without invoking browser specific or even operating system specific code, or depending on plugins. I can (as far as I know) only detect success, failure, and timeout. Above all, I want the site to operate purely on simple clean javascript that works on any popular browser, and ideally, even the unpopular javascript-enabled browsers.
I fear that "simple clean javascript that works on any popular browser" may be an unattainable goal. The jQuery library attempts to provide a uniform abstraction layer above the particular behaviour of individual browsers. I've found it useful, but my experience is limited, so I can't say whether it achieves all you'll need.
FWIW: I always check IPv4 as a control measure. I only complain when IPv6 fails but IPv4 worked. This catches the case of apache httpd being down; it catches power down; it doesn't catch more subtle problems. When the control is down, I discount it from the list of failures (grey instead of red; and the ISP test in particular stops counting it).
Not perfect; but if you can help me improve on this in a way that keeps my goal of simple javascript, I'm very much interested in your ideas. In some cases, it may be as simple as expertise (since JavaScript is not my "native tongue", so to speak).
We both share that pedigree! 8-)
Thanks for the feedback! And thanks for taking the time to read the document. A lot of people have put a lot of time into that document already. I'm hoping ultimately the community finds the document (and the site) useful.
Thanks for revealing more of the picture to me. ATB Niall
At Sun, 26 Oct 2014 20:08:41 +0000, Niall O'Reilly wrote:
I fear that "simple clean javascript that works on any popular browser" may be an unattainable goal. The jQuery library attempts to provide a uniform abstraction layer above the particular behaviour of individual browsers. I've found it useful, but my experience is limited, so I can't say whether it achieves all you'll need.
... including whether it fits your design constraints. ATB Niall
participants (3)
-
Jason Fesler -
Marco Hogewoning -
Niall O'Reilly