Karen E. Nielsen wrote: <SNIP> > So what you're saying is that the Tunnel Server can rely on the > information from the IPv4 layer and thus does not need glue > native IPv6 NUD-like mechanism on top of the IPv4 layer - ? Correct. > > The real way to fix this is doing egress/ingress filtering on IPv4... > > But many ISP's do not do any filtering at all, so tough luck. > > For that matter, the not so many IPv6 ISP's that are out there don't > > filter on IPv6 either, at least most of them, so most are > > repeating the > > same problem again, but all has to do with the router not > > being able to > > do filtering or something on linerate... > > Neither of these are real problems in the particular scenario of > zeroconf, due to its severe assumptions on IPv4 source filtering and > source spoof preventions. Which should indeed be there, but are not in most cases. Then again, using spoofing to do DDoS's is not needed when the kiddy people have 50k host big botnets at their disposal. > A different issue however is that the server may be swamped with > ICMP proto-41 unreachable from IPv4 nodes in the case where the > server is used to reflect packets into the network. I have seen quite a number of icmp unreachable's coming onto one of the Tunnel Servers we have, when people turned off their proto-41 or when the route was unavailable etc. Fortunatly these are only icmp's and thus doesn't cost most in terms of bandwidth etc. One of the solutions is proto41-Heartbeat, let the client send a heartbeat every now and then to the Tunnel Server, if it doesn't do that just shutdown the tunnel. Then again, I do not know of anyone having a Tunnel Server which has more than 5000 tunnels connected to it. Maybe the Hexago people have more experience in that direction of volume of users ? Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part