You can follow the assignments of such "socket numbers" for NCP in RFCs 349, 433, 503, 739, 750, and 755. RFCs 758, 762, 770, 776, and 790 address both socket numbers for NCP and port numbers for TCP/IP simultaneously. RFCs 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, 1700 continue that work for port numbers only and RFC 3232 finally switches it to an online database.
The fact that a request with a TTL smaller than 12 does not trigger a response does not mean the responder is the host after 12 hops. Assuming none of the previous hosts misbehaves (they could be increasing or at least not decreasing the TTL) you can only conclude that it is none of the later hosts, but it can still be any of the previous ones.
That leaves you with Comcast AND China Unicom hosts and, considering that the replies you see in the traceroute results can easily be spoofed, it can be any third party as well.
Possible scenarios include (I don't say they are more likely):
1. Comcast is producing the responses, but only does so if the request TTL is large enough to make you blame China Unicom.
2. China Unicom hands the packets over to a third party after just a few hops in their backbone. The third-party sends ICMP Time exceeded messages looking like they are from other China Unicom hosts to make you blame China Unicom.
Conclusion: This is either an obvious attack from within the China Unicom backbone OR a more sophisticated attack where the attacker wants to a) hide his identity and b) blame China Unicom for it (I can't think of a scenario where b) would be a by-product and not on purpose).
Just saying. The sentences in the post that include the words "prove" and "proven" are simply wrong.
Yeah, copying GitHub URLs sucks. You cannot actually select it with your mouse, since some creepy JavaScript interferes and selects it for you. the result is that it's selected, but not copied to PRIMARY, as you'd expect. I fall into this trap every single time.
Hence, only lubutu's comment ("-R is the recursion flag for ls, cp, rm, etc") is true, while _delirium ("-R is the POSIX-standard flag for recursive grep") is wrong, which means AIX is free to do whatever it wants with both the -r and the -R flags.
If it's not a load issue and neither some intended limitation to prevent load issues, somebody pulled it on purpose. ...which I actually included in not being able to handle HN. ;)
Another thought: Since rgrep is an alias for grep -r and grep -r has changed, the complete rgrep tool has changed and this can _not_ be fixed by using the "right" switch. Hence rgrep is useless for scripting now.
I've always used -r before, since it saves a key press. ;)
But I started using -R today, in the middle of a WTF event while inspecting some Python files, digging up a Debian bug report, inspecting the upstream change and posting this to HN.
I still think it's not the best idea for Debian (or any other system) to break compatibility with upstream, since this will lead to different behaviors on different systems, not only depending on version and vendor (GNU or *BSD). But of course, it could also lead to the change being reverted, which would be welcome (guess nobody relies on the new behavior yet).
The POSIX argument is definitely valid, but nevertheless GNU's grep has always supported -r and BSD versions do as well (although OpenBSD's man page reads "This implementation supports those options; however, their use is strongly discouraged."), so it just unnecessarily breaks existing stuff.
RFC 349:
RFCs 349, 433, and 503 also provided a list of conflicting socket numbers used on specific hosts.