On 15-May-19 04:22, Amos Rosenboim wrote: > Let me just clarify few points: > The suggested filter is not for the protocol, but for the 2002::/16 address > space.
Sure. But this is quite complicated; more complicated than I imagined when we invented 6to4. I really suggest reading https://tools.ietf.org/html/rfc6343 and then https://tools.ietf.org/html/rfc7526 carefully, for those that haven't done so. According to Google statistics, 6to4 has been immeasurably small for at least a year (0.00%), but I don't see why it would do you any harm. > Also the traffic I am seeing is between addresses within this prefix to > addresses of our native IPv6 users. That's exactly what you should see, IMHO. What % of total IPv6 traffic is that, as a matter of curiosity? > As for policy - we tend to be as permissive as we can, and we certainly > wouldn’t like to restrict what is left from p2p apps. No argument from me. Brian > > Amos > > Sent from my iPhone > > On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <[email protected] > <mailto:[email protected]>> wrote: > >> Hi Marc, >> >> >> >> I don’t agree. There are many users with tunnel brokers that use 6in4. If >> you filter 6to4 as a protocol, you’re also filtering all those users’ >> traffic. >> >> >> >> Not everybody is lucky enough to have native IPv6 support from its ISP. >> >> >> Saludos, >> >> Jordi >> >> >> >> >> >> >> >> El 14/5/19 17:46, "Marc Blanchet" >> <[email protected] >> <mailto:[email protected]> en >> nombre de [email protected] <mailto:[email protected]>> >> escribió: >> >> >> >> 6to4 has been a good transition technology to help deploy IPv6 in the early >> days. However, it has intrinsically bad latency issues as its routing is >> based on the underlying IPv4, which can be pretty bad for non 6to4 >> destinations (e.g. normal IPv6 addresses). Moreover, its IPv6 in IPv4 >> tunnelling technology is likely to be filtered by various intermediate >> devices in the path. My take is that we shall declare 6to4 over and dead, >> thank you very much for your service. So I would suggest to filter it. If >> not, users may get latency issues that will go into support calls >> unncessarily. >> >> Marc. >> >> On 14 May 2019, at 11:24, Amos Rosenboim wrote: >> >> Hello, >> >> >> >> >> >> As we are trying to tighten the security for IPv6 traffic in our >> network, I was looking for a reference IPv6 ingress filter. >> >> I came up with Job Snijders suggestion (thank you Job) that can be >> conveniently found at whois -h whois.ripe.net <http://whois.ripe.net> >> fltr-martian-v6 >> >> >> >> After applying the filter I noticed some traffic from 6to4 addresses >> (2002::/16) to our native IPv6 prefixes (residential users in this case). >> >> The traffic is a mix of both UDP and TCP but all on high port numbers on >> both destination and source. >> >> It seems to me like some P2P traffic, but I really can’t tell. >> >> >> >> This got me thinking, why should we filter these addresses at all ? >> >> I know 6to4 is mostly dead, but is it inherently bad ? >> >> >> >> And if so, why is the prefix (2002::/16) still being routed ? >> >> >> >> Thanks, >> >> >> >> Amos Rosenboim >> >> -- >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of the >> individual(s) named above and further non-explicilty authorized disclosure, >> copying, distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited and will be >> considered a criminal offense. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the contents of >> this information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply to the >> original sender to inform about this communication and delete it. >>
