[now with IPv6 WG address in cc:, actually] On 15/05/14 00:57, Jen Linkova wrote:
Hi Jan,
finally I've managed to summarize my comments to the doc ;)
Hi, thank you very much for all your comments. I'm bringing part of this discussion to IPv6 WG mailing list as it is of technical nature and I think it belongs here. I put all your comments in our issues tracker, reachable publicly at https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues
1) You suggest to have a local mirror of the test-ipv6. While it definitely makes sense, using the local mirror might hide some edge connectivity issues so it worth mentioning. We might recommend to use *both*.
Yes, absolutely. This diversity would also help the ISP to understand if he has any IPv6 issues in other parts of the network other than access ;)
2) Section 5 You provide detailed instruction on how to run ping, but then saying just 'check DNS settings' and even 'configure different servers' - support engineers who need explanations on ping, would need more detailed explanations on how to change DNS settings.
"If IPv4 is working but the page is unavaliable' - I'd assume that an engineer could not tell if 'IPv4 is working'. So IMHO we shall just say that if site is unreachange - troubleshoot as any other 'I can not open this page' v4-only case. If we believe that troubleshooting such case is in scope of this document, I'd suggest to include traceroute as a troubleshooting step.
seems as a good idea. let us think about that ;)
3) Helpdesk code section: I'd use different fonts/color to distinguish between 'fixed' and 'example' fields in the output.
4) Code 112 (v4 + broken Ipv6)
- can we show the process as a flowchart? if-then-else?
that's a bit hard one... do we have anybody specialized in flowcharts here?
For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if it is not,, the customer either has a misconfigured CPE (which has IPv6 enables while it should not), or there is other Ipv6-enabled device which is used as a router. Check CPE configuration/state for IPv6 and disable it if it has it enabled'.
- I'd re-phrase step 2 as smth like 'if IPv6 is offered to the customer and you manage their CPE, check if CPE has a approved firmware version. Upgrade it if it does not'.
- I'd say that grep (to find the IPv6 address on MacOS) should be 'grep -E "en|inet6" so interface name is visible (to avoid the scnario when addresses are assigned to wrong interface);
- the IPv6 addresses table is a little bit confusing: -- it contains 6to4 case which should not cause code 112 (as well as Teredo case); -- some sections say 'call theor router vendor for support'. I believe we shall clarify somewhere in the beginning of the document that we assume that the support deals with customers CPE and if it is not a case, those CPE-related instructions should be either 'escalate' or 'advise customer to contact their router vendor for support' (which in my reality would never happen.....:) -- as each section of the tabel has instructions (and the last row says 'escalate', it is not clear in which case the engieer should proceed to the next step (checking the home router config).
the section of home router config check is a little bit confusing. When we just say 'check the configuration of the device', it does not mean much as we don't specify what we are looking for. Maybe we shall say smth like: - 'if CPE is managed by your support, check if CPE is configured as per your internal documentation' (as we might say somewhere in the doc that in that case it is strongly recommended to have a separate how-to on what should be configured on those CPEs); - check if the LAN interface has IPv6 address from the ISP allocated range; - check on user device if it has routers's both link-local (fe80:...) and ISP-assigned address in the neighbor discovery cache (<provide commands); - check the routing table on the user's device; see if the default route points to the router's address. If not - check if DHCP and or RAs are enabled on the home router. - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops.
I think this are all good suggestions. We'll go through them during our authosr edit cycle meeting, probably during the IETF meeting in Toronto.
Code 46 Section - I'd sugegst to run traceroute to see where it stops. If traceroute does not show any issues - escalate. If it does outside of your network - contact the affected netwokr NOC.
ack...
IMHO a section should be added which explains what kind of information should be collected for an escalation. I'd suggest: - Ipv4 and Ipv6 traceroute; - ifconfig output - routing table output - maybe packet capture for the session which is having issues.
I think this is asking a bit too much to a first level helpdesk employee... I don't know... Cheers, Jan