Hi Jan, finally I've managed to summarize my comments to the doc ;) 0) the document says that the target audience is residential ISPs and enterprise IT helpdesk while most of troubleshooting steps are mostly applicable for residential ISPs as they imply that there are CPE/home devices/etc. Shall we create another doc for enterprise networks or just extend this one? 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*. 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. 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? 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. 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. 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. On Thu, Apr 10, 2014 at 12:41 PM, Jan Zorz @ go6.si <jan@go6.si> wrote:
Dear BCOP group,
I would like to get a short slot in BCOP TF meeting in Warsaw, I would like to present the 00 version of a draft "IPv6 troubleshooting for helpdesks"
The 00 draft can be found in PDF format here:
http://go6.si/ipv6-troubleshooting-for-helpdesks/ (find the link at the end of the text).
I would encourage you to read the text and comment in terms if this is something that could be the best current operational practice - and particularly I'm searching for people that would join the working pack and continue the technical IPv6 part in IPv6 WG, where we would like to check for IPv6 technical validity and soundness of the document.
Thank you very much, Jan Zorz
-- SY, Jen Linkova aka Furry