Mailing List Archive

https://tools.ietf.org/html/rfc7526

- Mark

> On 14 May 2019, at 17:24, Amos Rosenboim <amos@oasis-tech.net> 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 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
> --
>

6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the same protocol as other tunnels such as 6in4 (protocol 41).



https://www.ietf.org/rfc/rfc3056.txt



It works fine for peer to peer applications.



What the IETF deprecated is anycast for 6to4 relays:



https://tools.ietf.org/html/rfc7526



I believe Hurricane Electric still hosts 6to4 relays.


Regards,

Jordi







El 14/5/19 17:25, "Amos Rosenboim" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de amos@oasis-tech.net> escribió:



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 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.

While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and RFC
7526 is quite clear that 2002::/16 is still valid. However, it is perfectly
permissible to filter it, if that is the policy a network operator wishes
to enforce.

On Tue, May 14, 2019 at 10:30 AM JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> 6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the
> same protocol as other tunnels such as 6in4 (protocol 41).
>
>
>
> https://www.ietf.org/rfc/rfc3056.txt
>
>
>
> It works fine for peer to peer applications.
>
>
>
> What the IETF deprecated is anycast for 6to4 relays:
>
>
>
> https://tools.ietf.org/html/rfc7526
>
>
>
> I believe Hurricane Electric still hosts 6to4 relays.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> El 14/5/19 17:25, "Amos Rosenboim" <
> ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de
> amos@oasis-tech.net> escribió:
>
>
>
> 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 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.
>
>

--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

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 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
> --

Hi David,



I agree that this is an operator decision, however, you should consider implications of calls in your helpdesk because you’re breaking p2p apps.



I’ve heard many times “6to4” is deprecated, and people not always look at the RFCs to confirm what others tell (which is in this case incorrect), so they got a wrong impression of the real situation.


Regards,

Jordi







El 14/5/19 17:40, "David Farmer" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de farmer@umn.edu> escribió:



While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and RFC 7526 is quite clear that 2002::/16 is still valid. However, it is perfectly permissible to filter it, if that is the policy a network operator wishes to enforce.



On Tue, May 14, 2019 at 10:30 AM JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the same protocol as other tunnels such as 6in4 (protocol 41).



https://www.ietf.org/rfc/rfc3056.txt



It works fine for peer to peer applications.



What the IETF deprecated is anycast for 6to4 relays:



https://tools.ietf.org/html/rfc7526



I believe Hurricane Electric still hosts 6to4 relays.


Regards,

Jordi







El 14/5/19 17:25, "Amos Rosenboim" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de amos@oasis-tech.net> escribió:



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 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.




--

===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================



**********************************************
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.

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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de marc.blanchet@viagenie.ca> 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 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.

On 14 May 2019, at 11:50, JORDI PALET MARTINEZ 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.

no. if you filter 2002::/16 on the IPv6 side, you are not filtering
tunnel broker users.


Marc (who did implement and make it available a tunnel broker for years)

>
>
>
> Not everybody is lucky enough to have native IPv6 support from its
> ISP.
>
>
> Saludos,
>
> Jordi
>
>
>
>
>
>
>
> El 14/5/19 17:46, "Marc Blanchet"
> <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en
> nombre de marc.blanchet@viagenie.ca> 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 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.

Let me just clarify few points:
The suggested filter is not for the protocol, but for the 2002::/16 address space.

Also the traffic I am seeing is between addresses within this prefix to addresses of our native IPv6 users.

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.

Amos

Sent from my iPhone

On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <jordi.palet@consulintel.es<mailto:jordi.palet@consulintel.es>> 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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de<mailto:ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de marc.blanchet@viagenie.ca<mailto:marc.blanchet@viagenie.ca>> 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.

I know. In my first post I clearly stated the difference between the 6to4 and the anycast.



The problem is that some folks are saying “filter 6to4”, so I was trying to make clear the difference.


Regards,

Jordi







El 14/5/19 18:22, "Amos Rosenboim" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de amos@oasis-tech.net> escribió:



Let me just clarify few points:

The suggested filter is not for the protocol, but for the 2002::/16 address space.



Also the traffic I am seeing is between addresses within this prefix to addresses of our native IPv6 users.



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.

Amos



Sent from my iPhone


On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> 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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de marc.blanchet@viagenie.ca> 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 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.



**********************************************
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.

Hi,

On Tue, May 14, 2019 at 05:50:52PM +0200, JORDI PALET MARTINEZ wrote:
> 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.

6in4 is not 6to4.

6to4 with 2002:: addresses and anycast relays must die.

In flames. 10 years ago.

> Not everybody is lucky enough to have native IPv6 support from its ISP.

Those should either change ISP or just use IPv4. The days of cross-ISP
tunneling are *over*.

Either do it right, or do not do it at all.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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 <jordi.palet@consulintel.es <mailto:jordi.palet@consulintel.es>> 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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de <mailto:ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de marc.blanchet@viagenie.ca <mailto:marc.blanchet@viagenie.ca>> 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.
>>

6in4 needs manual configuration (or a TB).

6to4 is 6in4 with automatic configuration.

Living in a perfect world is ideal (I will love to have just one ISP with IPv6 in every country). But is not real.

Regards,
Jordi



?El 14/5/19 22:41, "Gert Doering" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de gert@space.net> escribió:

Hi,

On Tue, May 14, 2019 at 05:50:52PM +0200, JORDI PALET MARTINEZ wrote:
> 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.

6in4 is not 6to4.

6to4 with 2002:: addresses and anycast relays must die.

In flames. 10 years ago.

> Not everybody is lucky enough to have native IPv6 support from its ISP.

Those should either change ISP or just use IPv4. The days of cross-ISP
tunneling are *over*.

Either do it right, or do not do it at all.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279




**********************************************
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.

On Tue, May 14, 2019 at 11:22 AM Amos Rosenboim <amos@oasis-tech.net> wrote:

> Let me just clarify few points:
> The suggested filter is not for the protocol, but for the 2002::/16
> address space.
>
> Also the traffic I am seeing is between addresses within this prefix to
> addresses of our native IPv6 users.
>
> 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.
>

If you don't filter traffic for 2002::/16 I would suggest you pay attention
to the route you are accepting for 2002::/16. Maybe you shouldn't accept a
route for this from an ASN on another continent or maybe just run your own
gateway for this function. Oh, and if you run your own gateway you, and
your peers and providers, may need to allow traffic sourced
from 192.88.99.1 to leave your network, depending on the gateway software
you use.

If you do filter traffic for 2002::/16 you probably shouldn't accept a
route for 2002::/16 either.

Doing this right is complicated, filtering it is easy. While I personally
don't filter 2002::/16, I also don't condemn anyone that does filter it,
there are good arguments on both sides.


> Amos
>
> Sent from my iPhone
>
> On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> 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" <
> ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de en nombre de
> marc.blanchet@viagenie.ca> 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 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.
>
>

--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

I did not graph it or anything, but it's no more than a few Mbps.

Amos

Sent from my iPhone

On 14 May 2019, at 23:56, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:

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 <jordi.palet@consulintel.es<mailto:jordi.palet@consulintel.es> <mailto:jordi.palet@consulintel.es>> 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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de<mailto:ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> <mailto:ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de marc.blanchet@viagenie.ca<mailto:marc.blanchet@viagenie.ca> <mailto:marc.blanchet@viagenie.ca>> 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> <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.

Hi,

All the mentioned reasons for filtering were focused on the performance of 6to4, user experience and so on.
As our users get native IPv6 they are probably not impacted by these problems when accessing interactive services.
If they are serving or getting the latest episode of GoT from other users who are using 6to4 I see no reason to interfere.

Thanks for all the advice.

Amos

Sent from my iPhone

On 15 May 2019, at 00:21, David Farmer <farmer@umn.edu<mailto:farmer@umn.edu>> wrote:



On Tue, May 14, 2019 at 11:22 AM Amos Rosenboim <amos@oasis-tech.net<mailto:amos@oasis-tech.net>> wrote:
Let me just clarify few points:
The suggested filter is not for the protocol, but for the 2002::/16 address space.

Also the traffic I am seeing is between addresses within this prefix to addresses of our native IPv6 users.

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.

If you don't filter traffic for 2002::/16 I would suggest you pay attention to the route you are accepting for 2002::/16. Maybe you shouldn't accept a route for this from an ASN on another continent or maybe just run your own gateway for this function. Oh, and if you run your own gateway you, and your peers and providers, may need to allow traffic sourced from 192.88.99.1 to leave your network, depending on the gateway software you use.

If you do filter traffic for 2002::/16 you probably shouldn't accept a route for 2002::/16 either.

Doing this right is complicated, filtering it is easy. While I personally don't filter 2002::/16, I also don't condemn anyone that does filter it, there are good arguments on both sides.

Amos

Sent from my iPhone

On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <jordi.palet@consulintel.es<mailto:jordi.palet@consulintel.es>> 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" <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de<mailto:ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de marc.blanchet@viagenie.ca<mailto:marc.blanchet@viagenie.ca>> 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.



--
===============================================
David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

Hi,

On Tue, May 14, 2019 at 11:08:21PM +0200, JORDI PALET MARTINEZ wrote:
> 6in4 needs manual configuration (or a TB).
>
> 6to4 is 6in4 with automatic configuration.

You might not have noticed, but I have done a bit of IPv6 over time,
so yes, I understand. And thus: 6to4 needs to die. In flames.

> Living in a perfect world is ideal (I will love to have just one ISP with IPv6 in every country). But is not real.

This is not solved by poor-quality tunnels. All these tunnels do is
"make IPv6 look bad", so people get to learn "IPv6 has more latency, more
packet loss, and I can not even call customer support if it does not
work, so better avoid it".

This was already accepted truth 10+ years ago.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Anycast 6to4 needed to be assassinated, and that has more or less happened.
If classical unicast 6to4 is still working for a few people, I don't really
see any harm in it. Of course I agree that native is better.

Regards
Brian
(via tiny screen & keyboard)

On Wed, 15 May 2019, 19:00 Gert Doering, <gert@space.net> wrote:

> Hi,
>
> On Tue, May 14, 2019 at 11:08:21PM +0200, JORDI PALET MARTINEZ wrote:
> > 6in4 needs manual configuration (or a TB).
> >
> > 6to4 is 6in4 with automatic configuration.
>
> You might not have noticed, but I have done a bit of IPv6 over time,
> so yes, I understand. And thus: 6to4 needs to die. In flames.
>
> > Living in a perfect world is ideal (I will love to have just one ISP
> with IPv6 in every country). But is not real.
>
> This is not solved by poor-quality tunnels. All these tunnels do is
> "make IPv6 look bad", so people get to learn "IPv6 has more latency, more
> packet loss, and I can not even call customer support if it does not
> work, so better avoid it".
>
> This was already accepted truth 10+ years ago.
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
>

> Anycast 6to4 needed to be assassinated, and that has more or less happened. If classical unicast 6to4 is still working for a few people, I don't really see any harm in it. Of course I agree that native is better.

As far as I can tell there is really no flavour of 6to4 that can be deployed in a way where it works well.
Even without the anycast IPv4 route, the far end IPv6 node would have to have a good route back to 2002::/16.
If automatic tunnels are required 6RD contains all of the 6to4 issues within the ISP.

Cheers,
Ole

Well yes, there must be a return path, otherwise Amos would see no traffic.
Nobody is suggesting to *promote* 6to4, just no need to filter it.

Regards
Brian
(via tiny screen & keyboard)

On Wed, 15 May 2019, 21:56 Ole Troan, <otroan@employees.org> wrote:

> > Anycast 6to4 needed to be assassinated, and that has more or less
> happened. If classical unicast 6to4 is still working for a few people, I
> don't really see any harm in it. Of course I agree that native is better.
>
> As far as I can tell there is really no flavour of 6to4 that can be
> deployed in a way where it works well.
> Even without the anycast IPv4 route, the far end IPv6 node would have to
> have a good route back to 2002::/16.
> If automatic tunnels are required 6RD contains all of the 6to4 issues
> within the ISP.
>
> Cheers,
> Ole
>
>

Hi David,

> While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and RFC 7526 is quite clear that 2002::/16 is still valid. However, it is perfectly permissible to filter it, if that is the policy a network operator wishes to enforce.

With the 6to4 anycast relays deprecated the only 6to4 traffic should be src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic, which is not impacted by that filter.

Cheers,
Sander

On Thu, May 16, 2019 at 1:20 PM Sander Steffann <sander@steffann.nl> wrote:

> Hi David,
>
> > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and
> RFC 7526 is quite clear that 2002::/16 is still valid. However, it is
> perfectly permissible to filter it, if that is the policy a network
> operator wishes to enforce.
>
> With the 6to4 anycast relays deprecated the only 6to4 traffic should be
> src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves
> can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic,
> which is not impacted by that filter.
>

NO! RFC3056 Includes a gateway functionality it is just not Anycast. It is
possible to locally gateway traffic to native IPv6 and then you would get
traffic sourced from 2002::/16 and then you need to send traffic to a
return gateway. Now, most traffic you are seeing is probably coming from
the public anycast gateways that are still running, but it doesn't have to
be. As I said elsewhere in the thread, it complicated and filtering is
easy. Read RFC7526 very carefully, if you care, if you don't just filter it.

Thanks
--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

On 17-May-19 06:34, David Farmer wrote:
>
>
> On Thu, May 16, 2019 at 1:20 PM Sander Steffann <sander@steffann.nl <mailto:sander@steffann.nl>> wrote:
>
> Hi David,
>
> > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and RFC 7526 is quite clear that 2002::/16 is still valid. However, it is perfectly permissible to filter it, if that is the policy a network operator wishes to enforce.
>
> With the 6to4 anycast relays deprecated the only 6to4 traffic should be src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic, which is not impacted by that filter.
>
>
> NO! RFC3056 Includes a gateway functionality it is just not Anycast. 

Indeed. The Anycast hack was invented some time after 6to4 was standardised, and for a completely different purpose. Filtering the 6to4 IPv4 anycast address is a sensible thing to do for an IPv6-supporting ISP. Filtering 2002::/16 is unnecessary and breaks harmless traffic. (And there is so little such traffic that it is truly harmless.)

Brian

> It is possible to locally gateway traffic to native IPv6 and then you would get traffic sourced from 2002::/16 and then you need to send traffic to a return gateway.  Now, most traffic you are seeing is probably coming from the public anycast gateways that are still running, but it doesn't have to be. As I said elsewhere in the thread, it complicated and filtering is easy. Read RFC7526 very carefully, if you care, if you don't just filter it.
>
> Thanks
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================

Native IPv6 is clearly the right way to implement the service. However, my
question is "why filter 2002::/16?". It doesn't pose any more risk than a
native IPv6 address and there are some reasons to use it. Filtering it is
wrought with the possibilities for poor customer experience. My stance is
typically "don't filter $stuff unless you can identify a well defined
risk".

nb


On Thu, May 16, 2019 at 11:34 AM David Farmer <farmer@umn.edu> wrote:

>
>
> On Thu, May 16, 2019 at 1:20 PM Sander Steffann <sander@steffann.nl>
> wrote:
>
>> Hi David,
>>
>> > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and
>> RFC 7526 is quite clear that 2002::/16 is still valid. However, it is
>> perfectly permissible to filter it, if that is the policy a network
>> operator wishes to enforce.
>>
>> With the 6to4 anycast relays deprecated the only 6to4 traffic should be
>> src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves
>> can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic,
>> which is not impacted by that filter.
>>
>
> NO! RFC3056 Includes a gateway functionality it is just not Anycast. It
> is possible to locally gateway traffic to native IPv6 and then you would
> get traffic sourced from 2002::/16 and then you need to send traffic to a
> return gateway. Now, most traffic you are seeing is probably coming from
> the public anycast gateways that are still running, but it doesn't have to
> be. As I said elsewhere in the thread, it complicated and filtering is
> easy. Read RFC7526 very carefully, if you care, if you don't just filter it.
>
> Thanks
> --
> ===============================================
> David Farmer Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================
>

Hi,

On Thu, May 16, 2019 at 01:51:51PM -0700, Nick Buraglio wrote:
> Native IPv6 is clearly the right way to implement the service. However, my
> question is "why filter 2002::/16?". It doesn't pose any more risk than a
> native IPv6 address and there are some reasons to use it. Filtering it is
> wrought with the possibilities for poor customer experience. My stance is
> typically "don't filter $stuff unless you can identify a well defined
> risk".

Filtering it would allow the client to fall back to IPv4, instead of
letting it go onward with poor IPv6.

Unless you run a local relay you'll be hard pressed today to find any
case where 2002:: to *non* 2002:: traffic won't be significantly worse
than "just do IPv4" (in terms of "latency", "reliability", "packet loss").

2002:: to 2002:: is usually OK, as it follows the IPv4 path between
both sides (thus, same latency, packet loss, etc).

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279