Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

The problem is that you only realize about the DMARC problem is you "verify" 
your own emails when they come back from the list and you have configured the 
list to also send back the emails to you ...

Otherwise it passes unadvertised, but some people don't get emails from people 
that uses DMARC in strict mode, use gmail or yahoo, etc.

Not a complain, just to it is not "unadvertised".

Regards,
Jordi
@jordipalet
 
 

El 1/4/20 12:47, "Daniel Roesen" 
 escribió:

On Wed, Apr 01, 2020 at 10:01:21AM +0200, Webmaster wrote:
> By the way ... I just realized that the list is not handling correctly
> DMARC users. So my own emails when they come back, go to the spam
> folder, which means they are going to the spam folder of many folks.

One could argue that this is the problem of the DMARC user, expecting
the world to adjust to their personal believe how to combat the
deficiencies of email.

But I don't. :)

FYI, you're the first to complain/note a DMARC issue with the lists I'm
hosting (with >10k subs), so doesn't seem to be a widespread problem
yet.

> This was a problem with IETF and RIRs exploders and I believe they
> applied some patch or mailman/pipermail upgrade to resolve it.

I'm working on upgrading Mailman in the coming weeks and will also
revisit DMARC and other stuff at that point.


Best regards,
Daniel

PS: btw, you're posting as "webmaster@" - rly?

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0




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

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

El 1/4/20 10:55, "Tore Anderson" 
 escribió:

    * JORDI PALET MARTINEZ

> I don't know it by memory

Huh. In that case, what do you base your claims about what the GDPR 
requires on, exactly?

> 1) Before 25 May 2018, every EU citizen or resident must get a 
confirmation from any database holder with his personal data, to re-confirm the 
authorization.

Not true.

Assuming the lawful grounds for processing is «consent» pursuant to article 
6(1)(a) GDPR, and consent was given prior to 25th of May 2018 in a way that 
satisfies the requirements for consent pursuant to article 7 GDPR, then there 
is no need to ask the data subject to «re-confirm».

The process of subscribing to a mailing list does to me seem to constitute 
valid consent.

It would also be possible to instead the lawful grounds «necessary for the 
performance of a contract» pursuant to article 6(1)(b) GDPR, in which case 
valid consent is not required.

[Jordi] This is right *if* the list owner can demonstrate all the 
subscriptions. We don't know that.

The lack of a privacy statement is likely a bigger problem as far as GDPR 
compliance is concerned.


[Jordi] Agree, and my email intent was not to raise just if the list follows 
this or that GDPR article, but in general.


> 2) Right to object. Art. 59, but also many others. It is not probably 
clearly said that it must be in a footer but it must be clearly available how 
to.

It is most definitively not mentioned in the article 59 GDPR because that 
article about annual activity reports issued by the supervisory authorities, so 
that one totally irrelevant here.

You are right that there is a right to object (article 21 GDPR). However 
that has absolutely nothing to say about mailing list footers either.

Tore




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

Re: GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

Exactly, and I don’t think this data management policy, and GDPR compliance has 
been published in the list, and is available in the list web site when you 
register, etc.

 

The RFC is good, but GDPR is “agnostic” of RFCs … The DPA can say, even if you 
are RFC-folks, the list is open for any other folks to subscribe, and they 
don’t need to know that the list unsubscribe info is in the header, they may 
not even know how to see the header …

 

Believe me, I got similar resposes from the DPAs around the EU. 

 

Regards,

Jordi

@jordipalet

 

 

 

El 1/4/20 10:50, "Mohácsi János"  escribió:

 

Hi Jordi, 

In  my opinion to adhere the GDPR regulations each mailing list (maybe 
mailing list operator) should have a data management policy and implement some 
simple rules. The data management policy  should be made available during the 
subscription. If anything changes in the regulation or in the policy all 
subscribed users should be notified and allow them to unsubscribe. 
Unsubscription can be done with any mail receiving from the particular mailing 
list  since the modern mailing list managers follow the RFC 8058 

Regards, 

Janos Mohacsi 

 

On 2020. 04. 01. 10:33, JORDI PALET MARTINEZ wrote:
Hi Tore,
 
I've taken a quick look, because I don't know it by memory, but:
 
1) Before 25 May 2018, every EU citizen or resident must get a confirmation 
from any database holder with his personal data, to re-confirm the 
authorization. I'm not sure if that was done for this list. I believe this is 
art. 39 and some further text in the following articles.
 
2) Right to object. Art. 59, but also many others. It is not probably clearly 
said that it must be in a footer but it must be clearly available how to.
 
https://gdpr-info.eu/
 
I don't have any problem myself, but I think it is good for the host of the 
list to comply with GDPR, to avoid any DPA fine.
 
Regards,
Jordi
@jordipalet
 
 
 
El 1/4/20 10:11, "Tore Anderson" 
 escribió:
 
    * JORDI PALET MARTINEZ
    
> It is true however, that this list must follow GDPR, and this means 
having an explicit unsubscription link in the footer
    
Which GDPR article requires that, exactly?
    
Tore
    
 
 
 
**
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.
 
 
 
-- 
János Mohácsi
International R Officer
GÉANT activity coordinator in Hungary, EOSC GB member   
 
T: +36 30 555 7599
mohacsi.ja...@kifu.gov.hu
 
Kormányzati Informatikai Fejlesztési Ügynökség
 


Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a 
nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa 
meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, 
hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje 
az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön 
nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely 
csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel 
közölnie vagy azzal visszaélnie.

This message and any attachment are confidential and are legally privileged. It 
is intended solely for the use of the individual or entity to whom it is 
addressed and others authorised to receive it. If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. Please note that any dissemination, distribution, 
copying or use of or reliance upon the information contained in and transmitted 
with this e-mail by or to anyone other than the recipient designated above by 
the sender is unauthorised and strictly prohibited.




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

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

I agree that it is sufficient for smart people, but I'm not sure if in case 
somebody is not smart and make a complain to the DPA, they will agree being 
sufficient.

I'm just fine either way, just making sure that the list responsible avoids 
troubles because non-smart (not to say stupid) people.

Regards,
Jordi
@jordipalet
 
 

El 1/4/20 10:43, "Bjørn Mork" 
 escribió:

JORDI PALET MARTINEZ  writes:

> 2) Right to object. Art. 59, but also many others. It is not probably 
clear=
> ly said that it must be in a footer but it must be clearly available how 
to=
> .
>
> https://gdpr-info.eu/
>
> I don't have any problem myself, but I think it is good for the host of 
the=
>  list to comply with GDPR, to avoid any DPA fine.


This list has this in the header:

List-Id: IPv6 operators forum 
List-Unsubscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-requ...@lists.cluenet.de?subject=unsubscribe>
List-Archive: <http://lists.cluenet.de/pipermail/ipv6-ops>
List-Post: <mailto:ipv6-ops@lists.cluenet.de>
List-Help: <mailto:ipv6-ops-requ...@lists.cluenet.de?subject=help>
List-Subscribe: <http://lists.cluenet.de/mailman/listinfo/ipv6-ops>,
<mailto:ipv6-ops-requ...@lists.cluenet.de?subject=subscribe>


This is obviously more than sufficient.

There is not need to duplicate this in the footer to compensate for
buggy and user unfriendly email clients


Bjørn




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

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

Hi Tore,

I've taken a quick look, because I don't know it by memory, but:

1) Before 25 May 2018, every EU citizen or resident must get a confirmation 
from any database holder with his personal data, to re-confirm the 
authorization. I'm not sure if that was done for this list. I believe this is 
art. 39 and some further text in the following articles.

2) Right to object. Art. 59, but also many others. It is not probably clearly 
said that it must be in a footer but it must be clearly available how to.

https://gdpr-info.eu/

I don't have any problem myself, but I think it is good for the host of the 
list to comply with GDPR, to avoid any DPA fine.

Regards,
Jordi
@jordipalet
 
 

El 1/4/20 10:11, "Tore Anderson" 
 escribió:

    * JORDI PALET MARTINEZ

> It is true however, that this list must follow GDPR, and this means 
having an explicit unsubscription link in the footer

Which GDPR article requires that, exactly?

Tore




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

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

Well, we can't know probably, but he must be able to unsubscribe by himself 
anyway ...

It is true however, that this list must follow GDPR, and this means having an 
explicit unsubscription link in the footer, which will also facilitate some 
people to unsubscribe (yes we know, even having that footer, some people is not 
"able" to read it).

Regards,
Jordi
@jordipalet
 
 

El 1/4/20 9:46, "Daniel Roesen" 
 escribió:

On Wed, Apr 01, 2020 at 09:29:45AM +0200, JORDI PALET MARTINEZ wrote:
> If you’re receiving the messages is because YOU subscribed to the list.

Not necessarily. Especially with the big freemailers, email accounts
sometimes change owners... where old owner didn't unsub from all mailing
lists, especially the low volume ones.

I've taken care of that.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0




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

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[JORDI PALET MARTINEZ]

If you’re receiving the messages is because YOU subscribed to the list.

 

If you subscribed to the list, you know how to unsubscribe.

 

If you don’t know it, you should be smart enough to look into the email header 
and you will find how to do it.

 

Just in case you don’t know how to do it, here is it for you:

 

List-Unsubscribe: ,

    

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 1/4/20 6:08, "Sunita Badiga" 
 escribió:

 

STOP FUCKING EMAILING ME 

 

UNSUBSCRIBE



On Mar 31, 2020, at 8:35 PM, james machado  wrote:

 

The real problem is there are distinct use cases for both SLAAC and DHCPv6 and 
the people in charge of DHCPv6 keep screwing up.  It should be possible to run 
either SLAAC/RA or DHCPv6 and have each offering provide the required 
information without having to run additional services just to get basic feature 
parity to IPv4.  This is slowing implementation in enterprise networks.

 

james

 

 

On Tue, Mar 31, 2020 at 3:24 PM Brian E Carpenter  
wrote:

On 31-Mar-20 23:17, Mark Tinka wrote:
> 
> 
> On 31/Mar/20 12:09, sth...@nethelp.no wrote:
> 
>> Note that there have been multiple requests for DHCPv6 to do this but
>> every attempt has been shot down.
> 
> Yep - thankfully, we have an option.
> 
> Operating two address assignment protocols is just silly.
> 
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.

There's purism (which I don't understand) and there's also historical
baggage that is incredibly hard to get rid of. As I have reminded from
time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
became a proven technology for IPv4 (i.e. many of us were still running
around manually assigning IPv4 addresses to newly installed Suns and
NCDs and the like). DHCPv6 was an afterthought.

Unfortunately, the purism has made it impossible to have a rational
discussion about engineering our way out of this historical duplication.

On 01-Apr-20 05:01, Gert Doering wrote:

...
> As soon as you have a larger routed network, mDNS falls short, and 
> (unless you have a windows domain) there are no existing mechanisms
> to put a SLAAC v6 address into DNS...

I think there's no *deployed* mechanism. DynDNS is said to work in the
lab. There's also some hope that DNS-SD will alleviate this problem, 
but only if it gets deployed.

> Yes, thanks, IETF.  Well done.

It's not because nobody has tried. But the bridge between theory and
operations seems to be hard to cross.

On 01-Apr-20 07:21, James R Cutler wrote:

...
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and 
> DHCPv6 cooperative and complementary attributes of end-to-end networking? 

Well, duh. What we need is more people with real operational smarts
able to spend a lot of time and patience in the IETF. Yes, I know
why that is hard. (I had operation smarts once; no longer.) But that
is the only way we we can get a pragmatic approach into RFC text.

Don't worry about the travel budget, because the IETF is going to
have to do much more of its work remotely for the next couple of years
anyway. But the time and patience investment is substantial.

Stay well,
   Brian Carpenter



 



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

ideas for adding IPv6 support to existing Open Source apps

[JORDI PALET MARTINEZ]

Hi all,

The next AFRINIC meeting, middle of June, in Uganda, will host a 2-days 
hackathon to add IPv6 support to some apps.

We are trying to compile a list of Open Source applications that could be 
subject for this exercise.

I think a possible priority could be apps used by operators which still don't 
have IPv6 support.

If you have something in mind, please provide the URLs where to get the source 
and it must be possible to upload a patch afterwards, to take as much advantage 
as possible.

Thanks!

Regards,
Jordi



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

Re: IPv6 ingress filtering

[JORDI PALET MARTINEZ]

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" 
 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 14Aufsichtsratsvors.: 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.

Re: IPv6 ingress filtering

[JORDI PALET MARTINEZ]

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

Re: IPv6 ingress filtering

[JORDI PALET MARTINEZ]

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

Re: IPv6 ingress filtering

[JORDI PALET MARTINEZ]

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" 
 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 
 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" 
 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:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SEPhone: 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.

Re: IPv6 ingress filtering

[JORDI PALET MARTINEZ]

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

Re: question regarding over the counter devices

[JORDI PALET MARTINEZ]

I guess the point here is to compare if they also have IPv4 firewall on by 
default.

However, I believe the point here is to understand if a user having a 
“standard” distribution of any BSD/Linux, is the one that don’t double check 
all the security of that OS. Maybe we need to look into those distributions of 
BSD/Linux made for non-techie users, that come with a “build-in” GUI, etc. I 
doubt those come with IPv6-enabled by default and the firewall-off, it will be 
a mistake, as they try to allow the users to work with those distributions 
replacing a Windows (which of course comes with IPv6 enabled and IPv6 firewall 
enabled by default).

Regards,
Jordi
 

-Mensaje original-
De: 
Responder a: 
Fecha: miércoles, 1 de marzo de 2017, 9:44
Para: 
CC: , 
Asunto: Re: question regarding over the counter devices

> > IPv6 firewall non-on by default. I�$,1ryve not seen that myself in any 
product up to now.
> 
> How many products have you looked at? We're still talking about home 
> routers now, right?

I was commenting on "all the IPv6 OSs *for hosts and servers*, have the
IPv6 firewall on by default" (my emphasis). This would seem to include
all the BSD variants, all the Linux variants, etc. And in that case, the
statement "IPv6 firewall on by default" is clearly not true.

Steinar Haug, AS2116





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: question regarding over the counter devices

[JORDI PALET MARTINEZ]

Yes, CEs used for residential and SMEs.

In all the products I’ve seen, IPv6 was even on by default (again, IPv6-on, 
firewall-on, but by default). For example, this is true for several FTTH (with 
and without embedded ONT) and DSL CPEs that Spanish providers deliver to 
customers, even if they don’t provide IPv6 yet. I’ve seen the same situation in 
several of my customers, recently in Latin and Central America countries.

I’ve looked at different models of about 11-12 vendors, but was just 
using/configuring them, so not on purpose for checking this matter. I’m talking 
about my memory collection from about 4-5 years ago, so will not be easy to 
remember exact models/firmware versions, etc. In my own home, I’ve right now 
access to 4 vendors, 5 products in total, and all them have the IPv6 firewall 
on by default. I’ve another one from TP-Link that I believe was on, but it has 
been reflashed with OpenWRT first, now to LEDE, so I can’t check it anymore … 
Of course, OpenWRT/LEDE have it on by default.

I’m not sure if they keep a record of that, but may be Tim/Erica (in copy) from 
UNH, that perform IPv6 Ready certification, have this detail in some kind of 
statistics? May be even they can ask the other labs that do the testing 
worldwide.

Regards,
Jordi
 

-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Mikael Abrahamsson <swm...@swm.pp.se>
Organización: People's Front Against WWW
Responder a: <swm...@swm.pp.se>
Fecha: miércoles, 1 de marzo de 2017, 9:13
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: <ipv6-ops@lists.cluenet.de>
Asunto: Re: question regarding over the counter devices

On Wed, 1 Mar 2017, JORDI PALET MARTINEZ wrote:

> IPv6 firewall non-on by default. I’ve not seen that myself in any product 
up to now.

How many products have you looked at? We're still talking about home 
routers now, right?

I just checked Netgear R6100. Factory default has "IPv6 disabled", when I 
change it to "Auto Detect" the setting "IPv6 filtering" is "secured" by 
default.

So this seems to be same thing that you've been seeing.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: question regarding over the counter devices

[JORDI PALET MARTINEZ]

What I’ve seen, yes is on by default, but I also heard the same complain, but 
actually never seen a device not-on by default … so I’m not really convinced is 
very real.

However, I believe that all the IPv6 OSs for hosts and servers, have the IPv6 
firewall on by default, so this should not be a big issue, unless you have 
other devices with no IPv6 firewall (IP cameras?), which I think is not common, 
because those devices (what I’ve seen up to now), only respond to the port that 
they have designated to work on.

We had this debate several times in IETF I think …

There is some text about that in both RFC7084 (and bis that I’m working on 
https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-01) and RFC6092.

Regards,
Jordi
 

-Mensaje original-
De:  en nombre de 
Mikael Abrahamsson 
Organización: People's Front Against WWW
Responder a: 
Fecha: miércoles, 1 de marzo de 2017, 8:06
Para: 
Asunto: question regarding over the counter devices


Hi,

I just had a discussion with people from an ISP in the process of 
implementing IPv6. They were afraid of turning on IPv6 for customers who 
had purchased their own routers themselves, because these routers might 
not have IPv6 firewalling on by default, thus exposing customers who used 
to be "protected" by IPv4 NAT, to now be exposed with unfirewalled IPv6.

So my question:

Devices that people buy in electronics stores etc, do they even come with 
IPv6 turned on by default?

If they do, is firewalling turned on by default?

My Apple Airport Express at least came with firewalling turned on, I don't 
remember what the default setting was for IPv6 support. But if one turned 
on IPv6 support, then one had to unclick the firewall clickbox to be able 
to get incoming connections.

I'm going to check the devices I have in my boxes here at home, but in the 
mean time would appreciate if others could share their experiences.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: contact with One & One ?

[JORDI PALET MARTINEZ]

Right I missed that too, and now reading the article instead of “quick review”, 
I think the solution is there:

https://github.com/cloudflare/pmtud


Saludos,
Jordi


-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Paul Stewart <p...@paulstewart.org>
Responder a: <p...@paulstewart.org>
Fecha: viernes, 14 de octubre de 2016, 14:09
Para: Mikael Abrahamsson <swm...@swm.pp.se>
CC: <ipv6-ops@lists.cluenet.de>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
Asunto: Re: contact with One & One ?

You are correct - i misspoke on that … the reported issue from some 
visitors is site doesn’t load.  Sorry for the confusion - need more caffeine 
this morning :)

> On Oct 14, 2016, at 8:05 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> 
> On Fri, 14 Oct 2016, Paul Stewart wrote:
> 
>> honestly we’ve never fixed it.  it works for lots of customer/visitors 
but breaks for others (and they fail back to IPv4) - we thought it was
> 
> Errr, how does this fallback work? I am not aware of any such mechanism.
> 
> Happy Eyeballs is done when the SYN+ACK gets back.
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: contact with One & One ?

[JORDI PALET MARTINEZ]

The issue here is that customers (the ones that browse the broken web sites), 
don’t know about MTU, ICMP, etc.

So I guess is in your side as the “provider” of the content, who is the 
interested party in making sure it works for “all” your possible customers.

Up to now, every time I’ve seen this problem was just related to ICMPv6 being 
filtered, as many folks do in IPv4 …


By the way, interesting article, I didn’t read it before:
https://blog.cloudflare.com/path-mtu-discovery-in-practice/


Saludos,
Jordi


-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Paul Stewart <p...@paulstewart.org>
Responder a: <p...@paulstewart.org>
Fecha: viernes, 14 de octubre de 2016, 13:52
Para: Mikael Abrahamsson <swm...@swm.pp.se>
CC: <ipv6-ops@lists.cluenet.de>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
Asunto: Re: contact with One & One ?

At $$$job we run quite a bit of dual stack towards customers as an ISP 
(mainly PPPoE) - our own public website fails the PTB test and quite honestly 
we’ve never fixed it.  it works for lots of customer/visitors but breaks for 
others (and they fail back to IPv4) - we thought it was only external tunnel 
visitors but have found out otherwise… never fully understood what was going on 
and I keep meaning to look at it .. 

NGINX front ends load balanced via anycast … pretty standard Ubuntu 
16.04LTS setup on the server side.  From what I’ve read it seems to be an ECMP 
related problem like what CloudFlare published a blog about … 

Paul

> On Oct 14, 2016, at 7:45 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> 
> On Fri, 14 Oct 2016, JORDI PALET MARTINEZ wrote:
> 
>> I think is time to retire happy-eye-balls, it is the only way the people 
will react to those issues!
> 
> Happy eyeballs doesn't solve PMTU blackhole.
> 
> So this is actually customer breakage occuring, but I imagine lots of 
ISPs are actually doing MSS re-write and/or announcing lower than 1500 MTU on 
the customer LAN, so even if a customer has PPPoE with 1492 MTU, they still 
won't see this problem.
> 
> I have seen swedish authorities websites with same 
"won't-respond-to-PTB", no answer there either to fault reports.
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: contact with One & One ?

[JORDI PALET MARTINEZ]

I don’t think it will help …

I’ve got several of their customers, several *months* ago, which opened a 
ticket, and they didn’t get a solution/response …

It may happen that the folks in the ticketing system don’t understand the 
problem or don’t scale it or whatever …

I think is time to retire happy-eye-balls, it is the only way the people will 
react to those issues!

That’s why, the ideal will be to have a direct contact with the team that is 
working on IPv6 …

Saludos,
Jordi


-Mensaje original-
De:  en nombre de 
Kurt Jaeger 
Responder a: 
Fecha: viernes, 14 de octubre de 2016, 12:58
Para: Mikael Abrahamsson 
CC: 
Asunto: Re: contact with One & One ?

Hi!

> > www.corso-kino.de
> 
> Thanks.
> 
> If it helps, point them to this website (still in development/beta):
> 
> https://ipv6alizer.se/
> 
> The result is (verifies what you said):
> 
> INFO:  server-mss 1440, result: pmtud-fail
> ERROR: http://www.corso-kino.de don't listen to PTB

Thanks. It's just around the corner, and I think I can
get them to open a ticket with 1und1 8-}

-- 
p...@opsec.eu+49 171 3101372 4 years to 
go !





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: contact with One & One ?

[JORDI PALET MARTINEZ]

There’re tons of them !



Here are a couple of PMTUD test:


tbit from 2001:df0:4:4000::1:115 to 2001:8d8:1001:238f:3cf1:2223:88f2:c80a
server-mss 1440, result: pmtud-fail
app: http, url: http://diskmakerx.com/
[  0.009] TX SYN 64  seq = 0:0
[  0.288] RX SYN/ACK 64  seq = 0:1
[  0.288] TX 60  seq = 1:1
[  0.298] TX233  seq = 1:1(173)
[  0.577] RX 60  seq = 1:174  
[  0.812] RX   1500  seq = 1:174(1440)
[  0.812] RX   1500  seq = 1441:174(1440)  
[  0.812] RX   1500  seq = 2881:174(1440)  
[  0.812] RX 69  seq = 4321:174(9)
[  0.812] RX   1500  seq = 4330:174(1440)  
[  0.812] RX   1500  seq = 5770:174(1440)  
[  0.812] TX PTB   1280  mtu = 1280
[  0.812] RX   1500  seq = 7210:174(1440)  
[  0.816] RX   1500  seq = 8650:174(1440)  
[  0.822] TX 60  seq = 174:1  
[  0.883] RX   1500  seq = 10090:174(1440)
[  0.892] RX   1500  seq = 11530:174(1440)
[  1.651] RX   1500  seq = 1:174(1440)
[  1.651] TX PTB   1280  mtu = 1280
[  3.335] RX   1500  seq = 1:174(1440)
[  3.335] TX PTB   1280  mtu = 1280
[  6.703] RX   1500  seq = 1:174(1440)
[  6.703] TX PTB   1280  mtu = 1280
[ 13.439] RX   1500  seq = 1:174(1440)


tbit from 2001:df0:4:4000::1:115 to 2001:8d8:1000:d2ea:95d2:30d0:d4ad:9357
server-mss 1440, result: pmtud-fail
app: http, url: http://www.legalveritas.es/
[  0.009] TX SYN 64  seq = 0:0
[  0.285] RX SYN/ACK 64  seq = 0:1
[  0.285] TX 60  seq = 1:1
[  0.297] TX238  seq = 1:1(178)
[  0.572] RX 60  seq = 1:179  
[  0.810] RX   1492  seq = 1:179(1432)
[  0.810] TX PTB   1280  mtu = 1280
[  0.825] RX   1500  seq = 1433:179(1440)  
[  0.825] RX   1500  seq = 2873:179(1440)  
[  0.825] RX   1500  seq = 4313:179(1440)  
[  0.825] RX   1500  seq = 5753:179(1440)  
[  0.825] RX   1500  seq = 7193:179(1440)  
[  0.825] RX   1500  seq = 8633:179(1440)  
[  0.825] RX   1500  seq = 10073:179(1440)
[  0.825] RX   1500  seq = 11513:179(1440)
[  0.825] RX   1500  seq = 12953:179(1440)
[  1.636] RX   1492  seq = 1:179(1432)
[  1.636] TX PTB   1280  mtu = 1280
[  3.296] RX   1492  seq = 1:179(1432)
[  3.296] TX PTB   1280  mtu = 1280
[  6.616] RX   1492  seq = 1:179(1432)
[  6.616] TX PTB   1280  mtu = 1280
[ 13.248] RX   1492  seq = 1:179(1432)




Saludos,
Jordi


-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Mikael Abrahamsson <swm...@swm.pp.se>
Organización: People's Front Against WWW
Responder a: <swm...@swm.pp.se>
Fecha: viernes, 14 de octubre de 2016, 12:32
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: <ipv6-ops@lists.cluenet.de>
Asunto: Re: contact with One & One ?

    On Fri, 14 Oct 2016, JORDI PALET MARTINEZ wrote:

> Hi,
>
> I’ve discovered, several months ago already, that all the 1&1 web sites 
> with IPv6 support enabled are broken, because they filter PMTUD, so any 
> residential customer with has a reduced MTU because PPP or any other 
> encapsulation/tunnel, etc., is not reaching them.

Do you have an example of a website they host that I can test against?

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

contact with One & One ?

[JORDI PALET MARTINEZ]

Hi,

I’ve discovered, several months ago already, that all the 1&1 web sites with 
IPv6 support enabled are broken, because they filter PMTUD, so any residential 
customer with has a reduced MTU because PPP or any other encapsulation/tunnel, 
etc., is not reaching them.

I tried to contact someone at 1&1 and told their customer to pass the message, 
but nobody responded.

Anyone in the list is working for 1&1 or has the right contact?


Regards,
Jordi




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: CPE Residential IPv6 Security Poll

[JORDI PALET MARTINEZ]

I’ve promised an article to RIPE and APNIC … will work on it once I’ve the 
Korean data … hopefully in a couple of weeks …

If somebody can help to disseminate the survey among Korean ISPs, please, let 
me know!

In case someone in this list still didn’t responded, here is the link:

http://survey.consulintel.es/index.php/175122

Regards,
Jordi


-Mensaje original-
De: Tim Chown <tim.ch...@jisc.ac.uk>
Responder a: <tim.ch...@jisc.ac.uk>
Fecha: martes, 20 de septiembre de 2016, 15:55
Para: "jordi.pa...@consulintel.es" <jordi.pa...@consulintel.es>
CC: Benedikt Stockebrand <b...@stepladder-it.com>, IPv6 Ops list 
<ipv6-ops@lists.cluenet.de>, "Anfinsen, Ragnar" <ragnar.anfin...@altibox.no>
Asunto: Re: CPE Residential IPv6 Security Poll

Hi,

Thanks Jordi.  And yes, hindsight is always easy!

It would be nice to have a survey report document online for anyone to 
read, to complement various powerpoint decks you’ve used.

Amazing to get such a large response - well done :)
    
    Tim 
    
> On 20 Sep 2016, at 14:49, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es> wrote:
> 
> No, didn’t included anything about security, unfortunately (now I realize 
having missed it !) I will consider upgrading the actual questions or making a 
specific one related to security …
> 
> I’ve got already over 1.100 responses, and I’m waiting for Korean ISPs to 
start responding … I think is the only country which didn’t responded at all.
> 
> I did a quick presentation about the data both in the last v6ops and IEPG 
meetings. Will do a new presentation at the next LACNIC meeting and hopefully 
at the next RIPE one.
> 
> Regards,
> Jordi
> 
> 
> -Mensaje original-
> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en 
nombre de Tim Chown <tim.ch...@jisc.ac.uk>
> Responder a: <tim.ch...@jisc.ac.uk>
> Fecha: martes, 20 de septiembre de 2016, 14:50
> Para: Benedikt Stockebrand <b...@stepladder-it.com>, Jordi Palet Martinez 
<jordi.pa...@consulintel.es>
> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, "Anfinsen, Ragnar" 
<ragnar.anfin...@altibox.no>
> Asunto: Re: CPE Residential IPv6 Security Poll
> 
>Hi,
> 
>Was this one of the questions asked in Jordi’s survey?  I’m not sure 
I’ve seen the results published as yet, but he got a fantastic level of 
response (over 200 iirc)… Jordi? :)
> 
>Tim 
> 
>> On 20 Sep 2016, at 13:44, Benedikt Stockebrand <b...@stepladder-it.com> 
wrote:
>> 
>> Hi Ragnar and list,
>> 
>> as far as I can tell, little has changed at least in Germany since our
>> last discussion on this (except that I've since sobered up again:-)
>> 
>> I guess you won't be surprised that I still share the same opinion as
>> Ted:-)
>> 
>> So far all I've consciously seen on consumer CPEs is "per default, allow
>> all outbound, block all inbound".  I'm not sure if there are any ultra
>> cheap CPEs out that don't even let users configure inbound rules, but
>> I've never had the need to deal with anything like that.
>> 
>> However, one rather interesting thing has changed here: Since August
>> this year, ISPs can by law no longer force their customers in Germany to
>> use the CPE they provide.  The implications here are yet to appear, but
>> one possible effect might be that the ISPs move away from the
>> all-features-you-never-wanted-plus-some-extra CPEs they so far forced on
>> their customers to minimalistic devices they can just manage via TR-069
>> or similar (reaching a setup similar ot the old NT1/NT2 split with ISDN
>> in Europe), eventually leaving the filtering to the end user again.
>> 
>> With business customers the range obviously goes from "consumer grade is
>> good enough so why use anything else" for small businesses to dark fiber
>> for customers running their own AS.
>> 
>> 
>> Cheers,
>> 
>>   Benedikt
>> 
>> -- 
>> Benedikt Stockebrand,   Stepladder IT Training+Consulting
>> Dipl.-Inform.   http://www.stepladder-it.com/
>> 
>> Business Grade IPv6 --- Consulting, Training, Projects
>> 
>> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
>> 
> 
> 
> 
> 
> 
> 

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

In the router there is no DNS server configuration, so I guess it is using the 
IPv4 DNS servers, configured by DHCP (v4).

Regards,
Jordi









-Mensaje original-
De: <t...@pdxclouds.net>
Responder a: <t...@pdxclouds.net>
Fecha: viernes, 13 de mayo de 2016, 21:31
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
Asunto: Re: push apps failing in Android until you disable IPv6

>WhAt DNS servers are ipv6 DNS servers assigned  reply to list
>On May 13, 2016 11:57 AM, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
>wrote:
>>
>> Sorry the previous message was a repetition that was sent to the list 
>> several days ago, but because the attachment was not delivered. 
>>
>> I’ve got more info about the this. Right now they are trying Android with 
>> Wiko Fever latest version (5.1), but as said it happens with anyone they 
>> tried. 
>>
>> They have provided me screen captures of the CPE configuration. I can send 
>> them if someone want to see it, but in summary (Huawei HG8245H): 
>>
>> 1) IPv6 Default route is disabled 
>> 2) No static routers configured 
>> 3) LAN address fe80::1, no “parent” prefix. /64. Address prefix assignment 
>> mode SLAAC, other info assignment mode DHCPv6. 
>> 4) ULA disabled 
>>
>> Answering to Lorenzo email: There is not IPv6 in the cellular interface. 
>>
>> Erik, the guy who is providing me the info about this scenario, is asking me 
>> how he can “run” the ADB that you asked for ? 
>>
>> Regards, 
>> Jordi 
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Mensaje original----- 
>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre 
>> de Erik Kline <e...@google.com> 
>> Responder a: <e...@google.com> 
>> Fecha: martes, 10 de mayo de 2016, 15:34 
>> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es> 
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de> 
>> Asunto: Re: push apps failing in Android until you disable IPv6 
>>
>> >It's really not clear to me what that version of rdisc6 would print if 
>> >it encounters options about which it did not know anything.  A pcap of 
>> >just an RA would be best.  The adb commands I pasted should also 
>> >suffice to show what the device thinks it has for DNS, routes, 
>> >everything. 
>> > 
>> >On 10 May 2016 at 22:10, JORDI PALET MARTINEZ 
>> ><jordi.pa...@consulintel.es> wrote: 
>> >> Hi Erik, 
>> >> 
>> >> The rdisc6 is not providing the RDDNS info ? Is the first time I used it, 
>> >> actually trying to get it working on my Mac as well ;-) 
>> >> 
>> >> I will ask the rest of the info and provide it ASAP. 
>> >> 
>> >> I know is happening with Android version 4.4 y 5.1 (several vendors, I’ve 
>> >> asked for more concrete data). 
>> >> 
>> >> Regards, 
>> >> Jordi 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> -Mensaje original- 
>> >> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en 
>> >> nombre de Erik Kline <e...@google.com> 
>> >> Responder a: <e...@google.com> 
>> >> Fecha: martes, 10 de mayo de 2016, 14:57 
>> >> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es> 
>> >> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Mikael Abrahamsson 
>> >> <swm...@swm.pp.se> 
>> >> Asunto: Re: push apps failing in Android until you disable IPv6 
>> >> 
>> >>>More data, like the device type, the OS version, and whether or not 
>> >>>these RAs also include RDNSS information would be good. 
>> >>> 
>> >>>A bug report, or at the very least the output of: 
>> >>> 
>> >>>adb shell dumpsys connectivity 
>> >>> 
>> >>>and 
>> >>> 
>> >>>adb shell dumpsys connectivity --diag 
>> >>> 
>> >>>would help further diagnosis. 
>> >>> 
>> >> 
>> >> 
>>
>>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Sorry the previous message was a repetition that was sent to the list several 
days ago, but because the attachment was not delivered.

I’ve got more info about the this. Right now they are trying Android with Wiko 
Fever latest version (5.1), but as said it happens with anyone they tried.

They have provided me screen captures of the CPE configuration. I can send them 
if someone want to see it, but in summary (Huawei HG8245H):

1) IPv6 Default route is disabled
2) No static routers configured
3) LAN address fe80::1, no “parent” prefix. /64. Address prefix assignment mode 
SLAAC, other info assignment mode DHCPv6.
4) ULA disabled

Answering to Lorenzo email: There is not IPv6 in the cellular interface.

Erik, the guy who is providing me the info about this scenario, is asking me 
how he can “run” the ADB that you asked for ?

Regards,
Jordi








-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Erik Kline <e...@google.com>
Responder a: <e...@google.com>
Fecha: martes, 10 de mayo de 2016, 15:34
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>It's really not clear to me what that version of rdisc6 would print if
>it encounters options about which it did not know anything.  A pcap of
>just an RA would be best.  The adb commands I pasted should also
>suffice to show what the device thinks it has for DNS, routes,
>everything.
>
>On 10 May 2016 at 22:10, JORDI PALET MARTINEZ
><jordi.pa...@consulintel.es> wrote:
>> Hi Erik,
>>
>> The rdisc6 is not providing the RDDNS info ? Is the first time I used it, 
>> actually trying to get it working on my Mac as well ;-)
>>
>> I will ask the rest of the info and provide it ASAP.
>>
>> I know is happening with Android version 4.4 y 5.1 (several vendors, I’ve 
>> asked for more concrete data).
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>> -Mensaje original-
>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre 
>> de Erik Kline <e...@google.com>
>> Responder a: <e...@google.com>
>> Fecha: martes, 10 de mayo de 2016, 14:57
>> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Mikael Abrahamsson 
>> <swm...@swm.pp.se>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>>
>>>More data, like the device type, the OS version, and whether or not
>>>these RAs also include RDNSS information would be good.
>>>
>>>A bug report, or at the very least the output of:
>>>
>>>adb shell dumpsys connectivity
>>>
>>>and
>>>
>>>adb shell dumpsys connectivity --diag
>>>
>>>would help further diagnosis.
>>>
>>
>>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Understood, thanks !

I just read all the Doze thing :-) I also recall something published by Lorenzo 
about power saving in IPv6, etc., however, I still fail to see if there is no 
GUA, why Android is affected using only IPv4.

Regards,
Jordi








-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Phil Mayers <p.may...@imperial.ac.uk>
Responder a: <p.may...@imperial.ac.uk>
Fecha: martes, 10 de mayo de 2016, 15:01
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>, 
<ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>On 10/05/16 13:57, JORDI PALET MARTINEZ wrote:
>> Hi Phil,
>>
>> Not sure if you have seen the previous message with the rdisc6. Your
>> network may be not having a “broken” CPE.
>
>I did.
>
>You'd asked:
>
>"""
>Right, but how this is affecting IPv4 push notifications ?
>"""
>
>I was trying to convey that the wakeup system is complex, and that the 
>broken v6 might be causing the entire wakeup system to fail, including 
>the v4 bit, and to suggest some (wild guess) reasons as to the cause.
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Hi Erik,

The rdisc6 is not providing the RDDNS info ? Is the first time I used it, 
actually trying to get it working on my Mac as well ;-)

I will ask the rest of the info and provide it ASAP.

I know is happening with Android version 4.4 y 5.1 (several vendors, I’ve asked 
for more concrete data).

Regards,
Jordi








-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Erik Kline <e...@google.com>
Responder a: <e...@google.com>
Fecha: martes, 10 de mayo de 2016, 14:57
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Mikael Abrahamsson 
<swm...@swm.pp.se>
Asunto: Re: push apps failing in Android until you disable IPv6

>More data, like the device type, the OS version, and whether or not
>these RAs also include RDNSS information would be good.
>
>A bug report, or at the very least the output of:
>
>adb shell dumpsys connectivity
>
>and
>
>adb shell dumpsys connectivity --diag
>
>would help further diagnosis.
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Yes, they work in mobile only.

And they also work if you disable IPv6 in the router, so clearly I believe is 
related to the “wrong” announcement for the default gateway by the router not 
having a GUA, but I guess if there is only a link-local, the Android should not 
“try” anything with which impacts in IPv4 ?

Saludos,
Jordi









-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Mikael Abrahamsson <swm...@swm.pp.se>
Organización: People's Front Against WWW
Responder a: <swm...@swm.pp.se>
Fecha: martes, 10 de mayo de 2016, 14:08
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: <twarw...@gmail.com>, <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>On Tue, 10 May 2016, JORDI PALET MARTINEZ wrote:
>
>> But that will not explain why those notifications stop working once the 
>> devices is sleeping, and work again once you unlock the screen ?
>
>Do notifications work when the device is on mobile only? Without wifi 
>turned on at all?
>
>I don't remember the details but I seem to remember I've seen devices that 
>will turn off their wifi when they go to low power mode, and only keep 
>mobile data up.
>
>-- 
>Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

But that will not explain why those notifications stop working once the devices 
is sleeping, and work again once you unlock the screen ?

For example, you’re using your phone at our home. No IPv6, even if the router 
is announcing a default route having no GUA. Push notifications work.

At this point, is clear that the pull connection was done using IPv4.


Then you let the phone, so it comes to sleep mode, and notifications stop 
working until you wakeup the phone.

As said, in the same scenario, iOS devices are working.

Saludos,
Jordi








-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Trevor Warwick <twarw...@gmail.com>
Responder a: <twarw...@gmail.com>
Fecha: martes, 10 de mayo de 2016, 12:45
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>I think Push notifications are sent over a "Pull" connection (i.e. one that's 
>initiated by the android device to a central server). So if there is some 
>issue with creating outgoing connections in this scenario, that would cause 
>the problem you've seen.
>
>
>On 10 May 2016 at 09:58, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
>wrote:
>
>(Copied back to the list, as the list filtered the original message with the 
>screen capture attachment)
>
>For the info of the list. This is what the rdisc6 provided:
>
>Hop Limit:  64 (0x40)
>Stateful address cons.: No
>Stateful other cons.:   Yes
>Router preference:  medium
>Router lifetime:1800 (0x0708) seconds
>Reachable time: unspecified (0x)
>Retransmit time:unspecified (0x)
>
> MTU:   1472 bytes (valid)
> Source link-layer address: 2C:CF:58:E5:7C:C0
> From fe80::1
>
>Right, but how this is affecting IPv4 push notifications ?
>
>My understanding is that the servers doing the “push”, as the WAN link has not 
>got IPv6, are doing the push with IPv4.
>
>I could understand that Android may be slower to react to dual-stack traffic 
>because there is a default route announced by the router with no GUA, but 
>getting the push ?
>
>By the way, anyone got rdisc6 working in Mac OS X El Capitan ?
>
>Regards,
>Jordi
>
>
>
>
>
>
>
>
>
>-Mensaje original-
>De: Erik Kline <e...@google.com>
>Responder a: <e...@google.com>
>Fecha: martes, 10 de mayo de 2016, 4:41
>Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
>CC: Lorenzo Colitti <lore...@google.com>
>Asunto: Re: push apps failing in Android until you disable IPv6
>
>>Uh...non-zero router lifetime means it's announcing a default route.
>>That seems unwise.
>>
>>On 10 May 2016 at 02:49, JORDI PALET MARTINEZ
>><jordi.pa...@consulintel.es> wrote:
>>> Just got a “screen” capture from one of those situations (rdisc6).
>>>
>>> Hopefully is useful ! They made it from a virtual machine in the same 
>>> network as the Androids have the problema, having the VMware interfaces in 
>>> bridge mode.
>>>
>>> Saludos,
>>> Jordi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Mensaje original-
>>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en 
>>> nombre de Erik Kline <e...@google.com>
>>> Responder a: <e...@google.com>
>>> Fecha: lunes, 9 de mayo de 2016, 10:59
>>> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
>>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Lorenzo Colitti 
>>> <lore...@google.com>
>>> Asunto: Re: push apps failing in Android until you disable IPv6
>>>
>>>>If this router were to send out an RA advertising itself as a default
>>>>router in this configuration that would probably cause the symptoms
>>>>you're seeing.  That's why I asked for a sample of any RAs seen on
>>>>such a network.  (Such a configuration would of course be broken,
>>>>effectively requiring Happy Eyeballs to function at all.)
>>>>
>>>>On 9 May 2016 at 17:52, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
>>>>wrote:
>>>>> Hi Lorenzo,
>>>>>
>>>>> I don’t have an Android, so I can’t try myself, unfortunately, so I’m 
>>>>> just replicating what several folks told me in a training (people from 
>>>>> different ISPs, not just one).
>>>>>
>>>>> I’ve as

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

(Copied back to the list, as the list filtered the original message with the 
screen capture attachment)

For the info of the list. This is what the rdisc6 provided:

Hop Limit:  64 (0x40)
Stateful address cons.: No
Stateful other cons.:   Yes
Router preference:  medium
Router lifetime:1800 (0x0708) seconds
Reachable time: unspecified (0x)
Retransmit time:unspecified (0x)

 MTU:   1472 bytes (valid)
 Source link-layer address: 2C:CF:58:E5:7C:C0
 From fe80::1

Right, but how this is affecting IPv4 push notifications ?

My understanding is that the servers doing the “push”, as the WAN link has not 
got IPv6, are doing the push with IPv4.

I could understand that Android may be slower to react to dual-stack traffic 
because there is a default route announced by the router with no GUA, but 
getting the push ?

By the way, anyone got rdisc6 working in Mac OS X El Capitan ?

Regards,
Jordi









-Mensaje original-
De: Erik Kline <e...@google.com>
Responder a: <e...@google.com>
Fecha: martes, 10 de mayo de 2016, 4:41
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: Lorenzo Colitti <lore...@google.com>
Asunto: Re: push apps failing in Android until you disable IPv6

>Uh...non-zero router lifetime means it's announcing a default route.
>That seems unwise.
>
>On 10 May 2016 at 02:49, JORDI PALET MARTINEZ
><jordi.pa...@consulintel.es> wrote:
>> Just got a “screen” capture from one of those situations (rdisc6).
>>
>> Hopefully is useful ! They made it from a virtual machine in the same 
>> network as the Androids have the problema, having the VMware interfaces in 
>> bridge mode.
>>
>> Saludos,
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -Mensaje original-
>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre 
>> de Erik Kline <e...@google.com>
>> Responder a: <e...@google.com>
>> Fecha: lunes, 9 de mayo de 2016, 10:59
>> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Lorenzo Colitti 
>> <lore...@google.com>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>>
>>>If this router were to send out an RA advertising itself as a default
>>>router in this configuration that would probably cause the symptoms
>>>you're seeing.  That's why I asked for a sample of any RAs seen on
>>>such a network.  (Such a configuration would of course be broken,
>>>effectively requiring Happy Eyeballs to function at all.)
>>>
>>>On 9 May 2016 at 17:52, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
>>>wrote:
>>>> Hi Lorenzo,
>>>>
>>>> I don’t have an Android, so I can’t try myself, unfortunately, so I’m just 
>>>> replicating what several folks told me in a training (people from 
>>>> different ISPs, not just one).
>>>>
>>>> I’ve asked already a few days ago for more info, but still didn’t got it. 
>>>> I also asked to open a bug report as Erik suggested as well as the rdisc6 
>>>> from the same LAN.
>>>>
>>>> Let me try to write it down again the issue:
>>>>
>>>> 1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the 
>>>> router configs and the routers has link local, and you can ping with link 
>>>> local to the router in the LAN. Clearly, router has not GUA.
>>>>
>>>> 2) iPhone working fine.
>>>>
>>>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, 
>>>> when screen is off.
>>>>
>>>> 4) Disabling IPv6 in the router the problem disappears.
>>>>
>>>> 5) Complains to ISPs are responded with “disable IPv6 in the router”, is 
>>>> not useful at all :-(
>>>>
>>>> I can provide links to web pages from at least one “big” ISP, where they 
>>>> talk about this, but is in Spanish …
>>>>
>>>> I will ping right now again for more info and come back asap.
>>>>
>>>> Thanks !
>>>>
>>>> Regards,
>>>> Jordi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -Mensaje original-
>>>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en 
>>>> nombre de Lorenzo Colitti <lore...@google.com>
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Hi Tim,

I’ve asked for this info, but I’m almost sure (they show me a VNC from a remote 
location of the router config) that the router is only having link-local, ULA 
was disabled by default in the router (all the low cost CPEs that I’ve seen up 
to now, with IPv6 support, had ULA disabled by default).

Regards,
Jordi









-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Tim Chown <tim.ch...@jisc.ac.uk>
Responder a: <tim.ch...@jisc.ac.uk>
Fecha: lunes, 9 de mayo de 2016, 16:14
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: "ipv6-ops@lists.cluenet.de" <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>> On 9 May 2016, at 15:05, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
>> wrote:
>> 
>> Because if the ISP doesn’t offer IPv6 service, it can’t (or should not !) be 
>> IPv6, right ?
>
>It’s not unheard of for an ISP to update customer firmware for v6 support in 
>advance of deploying connectivity and addressing, with the result that the CPE 
>offers ULAs internally even though there's no IPv6 provisioning in place, and 
>3484-style devices then having issues.  Would be interesting as an aside to 
>know the status of 3484 vs 6724 on various OSes, as well as those like OSX 
>that appear to do their own thing.
>
>Tim
>
>> 
>> Saludos,
>> Jordi
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -Mensaje original-
>> De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre 
>> de jm33 <james...@gmail.com>
>> Responder a: <james...@gmail.com>
>> Fecha: lunes, 9 de mayo de 2016, 16:01
>> Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, <lore...@google.com>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>> 
>>> How do you know that the non-received notifications are IPv4 packets?
>>> 
>>> On Mon, May 9, 2016 at 4:52 AM, JORDI PALET MARTINEZ 
>>> <jordi.pa...@consulintel.es> wrote:
>>> 
>>> 
>>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when 
>>> screen is off.
>>> 
>>> 4) Disabling IPv6 in the router the problem disappears.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Hi Lorenzo,

I don’t have an Android, so I can’t try myself, unfortunately, so I’m just 
replicating what several folks told me in a training (people from different 
ISPs, not just one).

I’ve asked already a few days ago for more info, but still didn’t got it. I 
also asked to open a bug report as Erik suggested as well as the rdisc6 from 
the same LAN.

Let me try to write it down again the issue:

1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the 
router configs and the routers has link local, and you can ping with link local 
to the router in the LAN. Clearly, router has not GUA.

2) iPhone working fine.

3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when 
screen is off.

4) Disabling IPv6 in the router the problem disappears.

5) Complains to ISPs are responded with “disable IPv6 in the router”, is not 
useful at all :-(

I can provide links to web pages from at least one “big” ISP, where they talk 
about this, but is in Spanish …

I will ping right now again for more info and come back asap.

Thanks !

Regards,
Jordi









-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Lorenzo Colitti <lore...@google.com>
Responder a: <lore...@google.com>
Fecha: lunes, 9 de mayo de 2016, 10:41
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>Jordi,
>from your report it's not clear what the problem is. You say that the problem 
>disappears when IPv6 is disabled on the router, but then you say that it also 
>happens on an IPv4-only network. How can those statements both be true?
>
>It's not usually possible to disable IPv6 on an Android device unless the 
>device is rooted, which usually involves installing a non-stock build which 
>may behave differently.
>
>Also, please clarify what device you're talking about. Stock Android should 
>not have this problem, but some OEMs are known to drop IPv6 packets when the 
>screen is off.
>
>Cheers,
>Lorenzo
>
>On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ 
><jordi.pa...@consulintel.es> wrote:
>
>Hi,
>
>I’m not an Android user, but while doing and IPv6 training, many folks in the 
>meeting room told me that they needed to disable IPv6 in the router/Android 
>devices, otherwise they aren’t getting the notifications from WhatsApp, 
>Facebook, and many other apps.
>
>We have tried disabling energy saving options in Android, and it seems the 
>problems is not there. Basically, if the Android device is in stand-by, 
>notifications don’t come, until you “open” the Android. Apple and Windows 
>devices don’t have this problem.
>
>The scenario seems to happen regardless of the type of CPE (some observed this 
>with ADSL, others with GPON).
>
>Just for having a “stable scenario” were to try, we have actually replicated 
>this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B 
>and firmware v V3R013C00S106.
>
>We have tried using both the ONT as the wireless AP and also disabling the 
>WiFi on the ONT and using an external AP. Same problem in both situations.
>
>Don’t look like an issue related to a specific ISP, because the situation 
>happens in many different ISPs, and of course none of them provides IPv6 :-(
>
>I’m specially worried because the ISPs are telling the users to disable IPv6 
>everywhere …
>
>Any hints ?
>
>Regards,
>Jordi
>
>
>
>
>
>
>
>
>
>
>
>

Re: push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

No, I think is a different issue.

In our case the problem is happening in an IPv4-only network.

For some reason, some bug (I believe) in the IPv6 stack, is avoiding the phone 
to get the push notifications, until you unlock the screen.

Disabling IPv6 (even if is actually not being used), kills the problem. By 
killing IPv6 you disable the stack, and thus no link-local addresses ? But 
clearly seems a problem related to the way the Android is managing the WiFi 
when IPv6 is enabled, even if only link-local is available.

Reading the post you provided, it looks like IPv4 is still working well ?

Saludos,
Jordi









-Mensaje original-
De: <ipv6-ops-bounces+jordi.palet=consulintel...@lists.cluenet.de> en nombre de 
Erik Nygren <e...@nygren.org>
Responder a: <e...@nygren.org>
Fecha: sábado, 30 de abril de 2016, 17:33
Para: Jordi Palet Martinez <jordi.pa...@consulintel.es>
CC: IPv6 operators forum <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>At least on some Samsung devices there is this known issue where they drop 
>IPv6 packets when screen-saved.
>
>This is fixed n the Galaxy S7 apparently (I haven't tested myself).  I agree 
>this is a major problem...
>
>http://developer.samsung.com/forum/board/thread/view.do?boardName=General=239890
>http://www.gossamer-threads.com/lists/nsp/ipv6/54641
>
>
>
>On Sat, Apr 30, 2016 at 8:03 AM, JORDI PALET MARTINEZ 
><jordi.pa...@consulintel.es> wrote:
>
>Hi,
>
>I’m not an Android user, but while doing and IPv6 training, many folks in the 
>meeting room told me that they needed to disable IPv6 in the router/Android 
>devices, otherwise they aren’t getting the notifications from WhatsApp, 
>Facebook, and many other apps.
>
>We have tried disabling energy saving options in Android, and it seems the 
>problems is not there. Basically, if the Android device is in stand-by, 
>notifications don’t come, until you “open” the Android. Apple and Windows 
>devices don’t have this problem.
>
>The scenario seems to happen regardless of the type of CPE (some observed this 
>with ADSL, others with GPON).
>
>Just for having a “stable scenario” were to try, we have actually replicated 
>this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B 
>and firmware v V3R013C00S106.
>
>We have tried using both the ONT as the wireless AP and also disabling the 
>WiFi on the ONT and using an external AP. Same problem in both situations.
>
>Don’t look like an issue related to a specific ISP, because the situation 
>happens in many different ISPs, and of course none of them provides IPv6 :-(
>
>I’m specially worried because the ISPs are telling the users to disable IPv6 
>everywhere …
>
>Any hints ?
>
>Regards,
>Jordi
>
>
>
>
>
>
>
>
>
>
>

push apps failing in Android until you disable IPv6

[JORDI PALET MARTINEZ]

Hi,

I’m not an Android user, but while doing and IPv6 training, many folks in the 
meeting room told me that they needed to disable IPv6 in the router/Android 
devices, otherwise they aren’t getting the notifications from WhatsApp, 
Facebook, and many other apps.

We have tried disabling energy saving options in Android, and it seems the 
problems is not there. Basically, if the Android device is in stand-by, 
notifications don’t come, until you “open” the Android. Apple and Windows 
devices don’t have this problem.

The scenario seems to happen regardless of the type of CPE (some observed this 
with ADSL, others with GPON).

Just for having a “stable scenario” were to try, we have actually replicated 
this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B 
and firmware v V3R013C00S106.

We have tried using both the ONT as the wireless AP and also disabling the WiFi 
on the ONT and using an external AP. Same problem in both situations.

Don’t look like an issue related to a specific ISP, because the situation 
happens in many different ISPs, and of course none of them provides IPv6 :-(

I’m specially worried because the ISPs are telling the users to disable IPv6 
everywhere …

Any hints ?

Regards,
Jordi