General IPv6 Deployment issues (Was: Google and IPv6)

Jeroen Massar jeroen at unfix.org
Mon Mar 17 12:47:27 CET 2008


Matt Ryanczak wrote:
[..]
> We still have occasional complaints about reachability to www.arin.net.
> It does seem that 99% of that is PMTU issues (tunnels). We've also found
> that some people are not interested in troubleshooting with us[..]

What would be very welcome here, if you really want people to contact 
you when there are issues, is to have a public traceroute6 (or if 
possible tracepath6) utility available on the website that does both 
IPv4 and IPv6.

Generally PTMU issues come hand in hand together with broken routing.
Thus if you can provide a tracepath6 tool then people can directly check 
where it might go wrong, instead of only having to tell you "it is 
broken", and the route swaps and it works again, then you get the 
report, you check, and all is fine. Thus being able for the person who 
notices it to debug a bit can be very handy. Also IMHO it is very mature 
and responsible of an ISP to show the inner workings of their network, 
as it shows that they trust their own network and are willing to share 
and acknowledge problems they might have.

Also note, in the ranking of 'ipv6 brokenness' the list is IMHO:

  - Blackholing DNS caches/resolvers
    Thus ones that either respond with a broken packet or ones
    that simply ignore it completely and the ones that respond gibberish
    about every request about that label after getting a request for an
    AAAA one.

  - PMTU
    Either because it is filtered or because some link has a
    misconfigured MTU or some box is broken

  - ICMP filtering in general

  - 6to4
    Relays tend to be setup incorrectly and the forward/reverse path
    tends to go half way around the world and packets get pulled in to
    all kinds of directions: IPv4 BGP has an effect on forward and
    the reverse path, and so has IPv6 BGP on the same packets on also
    the forward and reverse path. Try debugging that mess, when some box
    somewhere drops packets or sends them to a blackhole.
    My advice: 6to4 is fine for clients but for servers nononononoooo....

Of course all of this also boils down to having an (easy) way of 
notifying the participants of a problem and that people actually report 
these problems in a correct manner, thus not only "it is broken". This 
goes for IPv4 and for IPv6 as well.

We have INOC-DBA, but it seems not to get used for this purpose and 
emailing the actual noc, when they have a visible contact address, seems 
to not happen either, whining on IRC of course does happen, but then you 
have to have luck that the whine actually ends up on the right persons desk.

Greets,
  Jeroen

(Who made http://www.sixxs.net/tools/traceroute/ for a reason, and 
/contact/ too etc etc, but still people seem not to be able to use that 
and thus use some remote far far away box and then are like 'it works 
there', yep, indeed, but that goes way around the problem ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080317/d29e196b/signature.bin


More information about the ipv6-ops mailing list