On 15/10/2016 00:57, Holger Zuleger wrote:
>> If the delegated prefix changes, you'll be simply postponing the local
>> communication failure, not prevent it.
> Only if the new prefix is different to the old one.
>
>> The last year has convinced me that the best user experience is
>> achieved by h
On 14/10/2016 23:32, Gert Doering wrote:
> Hi,
>
> On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote:
>> Of course the default route should *not* be withdrawn.
>> The RA default router announcement says just, "Hey hosts, I'm the way
>> out of your local subnet", and not "Hey host, I h
Has this been confirmed? What is next?
On Fri, Oct 14, 2016 at 5:59 AM, Harald F. Karlsen wrote:
> On 11.10.2016 18:37, Marcus Keane wrote:
>
>> We've raised it with the product group and we are investigating further.
>>
> Great! Also feel free to keep us updated on any findings here on the lis
On 14/10/2016 23:20, Thomas Schäfer wrote:
> I was wrong. Randomly set: no, manually change possible: yes.
> The reason for my confusion was "::" versus ":"
> Sometimes reading ipv6-addresses is hard.
Yes, and in fact my box has that feature. So thanks again!
Brian
On 14/10/2016 21:07, Thomas Schäfer wrote:
> Am 13.10.2016 um 21:56 schrieb Brian E Carpenter:
>> On 13/10/2016 21:14, Lorenzo Colitti wrote:
>>> Of note is the fact that the ULA prefix being announced is the ubiquitous
>>> fd00::/64.
>>
>> 0 is a perfectly random number, just like the ubiquitous P
On 14.10.2016 15:26, otr...@employees.org wrote:
> Holger,
>
>>>
>> Imagine a setup with *two* routers. One of them has broken Internet,
>> the other is working. How can the hosts decide if both keep announcing
>> themselves as "I can reach anything"?
>
> in the general cas
On 14.10.2016 15:20, sth...@nethelp.no wrote:
>> At the end, the whole behavior is because some host have problems in
>> handling situations where they have an IPv6 address configured and now
>> internet connectivity. But the solution to this requires that the host
>> is able to understand and wo
Holger,
>>
> Imagine a setup with *two* routers. One of them has broken Internet,
> the other is working. How can the hosts decide if both keep announcing
> themselves as "I can reach anything"?
in the general case the host still has to take the 'I can reach anything'
>>
> At the end, the whole behavior is because some host have problems in
> handling situations where they have an IPv6 address configured and now
> internet connectivity. But the solution to this requires that the host
> is able to understand and work with RIO options, which seams to be "at
> the tim
On 14.10.2016 14:33, otr...@employees.org wrote:
> Holger,
>
Imagine a setup with *two* routers. One of them has broken Internet,
the other is working. How can the hosts decide if both keep announcing
themselves as "I can reach anything"?
>>>
>>> in the general case the host sti
Holger,
>>> Imagine a setup with *two* routers. One of them has broken Internet,
>>> the other is working. How can the hosts decide if both keep announcing
>>> themselves as "I can reach anything"?
>>
>> in the general case the host still has to take the 'I can reach anything'
>> announcement
Yes and my understanding with ECMP on the network side is that this is exactly
what’s happening … and that’s what Cloudflare blog entry is referring to as
well …
I need to dig into this further - their code on Github for the fix I don’t
believe will work in our network architecture… although w
On Fri, 14 Oct 2016, JORDI PALET MARTINEZ wrote:
Up to now, every time I’ve seen this problem was just related to ICMPv6
being filtered, as many folks do in IPv4 …
I know several cases where the problem was that the load balancer didn't
forward the ICMPv6 PTB to the correct host and didn't ha
Am 14.10.2016 um 13:57 schrieb Holger Zuleger:
If the delegated prefix changes, you'll be simply postponing the local
communication failure, not prevent it.
Only if the new prefix is different to the old one.
I get never the same prefix! (ISP DTAG, private consumer)
The last year has conv
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: en nombre de
Paul Stewart
Responder a:
Fecha: viernes, 14 de octubre de 2016, 14:09
Para: Mikael
>> Imagine a setup with *two* routers. One of them has broken Internet,
>> the other is working. How can the hosts decide if both keep announcing
>> themselves as "I can reach anything"?
>
> in the general case the host still has to take the 'I can reach anything'
> announcement with a pinch of
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 wrote:
>
> On Fri, 14 Oct 2016, Paul Stewart wrote:
>
>> honestly we’ve never fixed
Thanks .. I meant to include link to that article - appreciate you doing so :)
We don’t filter ICMPv6 on those servers and the problem we are pretty confident
is ECMP related (as per what we learned from the Cloudflare blog) … need to set
up some time to look deeper though as internally and on o
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+A
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
> If the delegated prefix changes, you'll be simply postponing the local
> communication failure, not prevent it.
Only if the new prefix is different to the old one.
> The last year has convinced me that the best user experience is
> achieved by having an in-home stable ULA prefix to complement th
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
On 14.10.2016 12:32, Gert Doering wrote:
> Hi,
>
> On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote:
>> Of course the default route should *not* be withdrawn.
>> The RA default router announcement says just, "Hey hosts, I'm the way
>> out of your local subnet", and not "Hey host, I
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
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 h
* Holger Zuleger
> Hmm, what's so bad with still using the global prefix until the global
> connectivity comes back and the CPE gets a new one?
> Than it's early enough to set the preferred time of the former prefix to
> 0 and let them time out.
> In this way all local communication will not be i
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. I
On Fri, 14 Oct 2016, Kurt Jaeger wrote:
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 P
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
14 okt. 2016 kl. 12:38 skrev Kurt Jaeger
mailto:ipv6-...@c0mplx.org>>:
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
encapsu
> On 14 Oct 2016, at 12:32, Gert Doering wrote:
>
> Hi,
>
> On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote:
>> Of course the default route should *not* be withdrawn.
>> The RA default router announcement says just, "Hey hosts, I'm the way
>> out of your local subnet", and not "H
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
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.
Hi,
On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote:
> Of course the default route should *not* be withdrawn.
> The RA default router announcement says just, "Hey hosts, I'm the way
> out of your local subnet", and not "Hey host, I have a upstream
> connection to the rest of the int
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
I was wrong. Randomly set: no, manually change possible: yes.
The reason for my confusion was "::" versus ":"
Sometimes reading ipv6-addresses is hard.
>> Great idea, ULAs.
>
> In the right circumstances, yes, actually. And actually my circumstances
> yesterday were right for a ULA prefix: the ISP failed to give my CE a prefix.
> Today, they gave me a prefix, and so Linux gives me a default route.
Hmm, what's so bad with still using the global pr
On 11.10.2016 18:37, Marcus Keane wrote:
We've raised it with the product group and we are investigating further.
Great! Also feel free to keep us updated on any findings here on the
list (especially the ship vehicle and date for the fix).
--
Harald
Am 13.10.2016 um 21:56 schrieb Brian E Carpenter:
On 13/10/2016 21:14, Lorenzo Colitti wrote:
Of note is the fact that the ULA prefix being announced is the ubiquitous
fd00::/64.
0 is a perfectly random number, just like the ubiquitous PIN code 1234.
But yes, this a sloppy job by the FritzBox
39 matches
Mail list logo
