Mailing List Archive

> On 3 Nov 2014, at 6:43 pm, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
>
> [.As a side note, it seems that the European 'google' statistics are now more in line with the expectation]
>
> Several countries have recently made good progress dixit Google & Apnic (URL are simply a different way of presenting Google data):
> • US has reached 10%, welcome to the 10%-club
> • Estonia has a VERY impressive growth approaching 5%: https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
> • Other European countries with a recent growth:
> • Austria: https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
> • Czech republic: https://www.vyncke.org/ipv6status/plotpenetration.php?country=cz

Telefonica Czech Republic: http://stats.labs.apnic.net/ipv6/AS5610?a=5610&c=CZ&x=1&s=1&p=1&w=1&s=0

> • Norway: https://www.vyncke.org/ipv6status/plotpenetration.php?country=no

Telenor : http://stats.labs.apnic.net/ipv6/AS2119?a=2119&c=NO&x=0&s=1&p=1&w=10&s=0


> • Greece: https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr

Hellenic Telecommunications: http://stats.labs.apnic.net/ipv6/AS6799?a=6799&c=GR&x=1&s=1&p=1&w=1&s=0


> • Portugal: https://www.vyncke.org/ipv6status/plotpenetration.php?country=pt


Telepac PT : http://stats.labs.apnic.net/ipv6/AS3243?a=3243&c=PT&x=1&s=1&p=1&w=1&s=0


> If you are behind those growths, I would love to hear more details: technology used, issues, …
>

Gepff

I work with the residential gateways in Telenor Norway. We have two linux based Zyxel devices which support IPv6 native. We have done pilot trials since approx Easter, and since this summer we have started rolling out IPv6 where we can. Not all dslams support IPv6 native, and there is other restrictions as well. But we will be able to provide IPv6 to a majority of the user base within the year. Given that the user has a IPv6 capable RG.

We have some trouble understanding the September dip in the graph, as we have not done a rollback. We were in fact rolling out in that time period.
http://stats.labs.apnic.net/ipv6/AS2119?a=2119&c=NO&x=0&s=1&p=1&w=10&s=0

As for lessons learned, start slow. Try and catch as many bugs as possible before doing a large scale roll out. Even when hitting bugs, try and understand user impact before panicking. Browsers has pretty aggressive "happy eyeballs" algorithms, so you can get away with some (seldom occurring) bugs in production.

We use the same principle for IPv6 security as for IPv4 security. Meaning state full firewall blocking all incoming traffic, allowing all outgoing. But the user has full control to do as she likes.


-Erik Taraldsen



________________________________________
Fra: ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de [ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de] p&#229; vegne av Geoff Huston [gih@apnic.net]
Sendt: 3. november 2014 09:25
Til: Eric Vyncke (evyncke)
Kopi: ipv6-ops@lists.cluenet.de
Emne: Re: Some very nice IPv6 growth as measured by Google

> On 3 Nov 2014, at 6:43 pm, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
>
> [.As a side note, it seems that the European 'google' statistics are now more in line with the expectation]
>
> Several countries have recently made good progress dixit Google & Apnic (URL are simply a different way of presenting Google data):
> • US has reached 10%, welcome to the 10%-club
> • Estonia has a VERY impressive growth approaching 5%: https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
> • Other European countries with a recent growth:
> • Austria: https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
> • Czech republic: https://www.vyncke.org/ipv6status/plotpenetration.php?country=cz

Telefonica Czech Republic: http://stats.labs.apnic.net/ipv6/AS5610?a=5610&c=CZ&x=1&s=1&p=1&w=1&s=0

> • Norway: https://www.vyncke.org/ipv6status/plotpenetration.php?country=no

Telenor : http://stats.labs.apnic.net/ipv6/AS2119?a=2119&c=NO&x=0&s=1&p=1&w=10&s=0


> • Greece: https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr

Hellenic Telecommunications: http://stats.labs.apnic.net/ipv6/AS6799?a=6799&c=GR&x=1&s=1&p=1&w=1&s=0


> • Portugal: https://www.vyncke.org/ipv6status/plotpenetration.php?country=pt


Telepac PT : http://stats.labs.apnic.net/ipv6/AS3243?a=3243&c=PT&x=1&s=1&p=1&w=1&s=0


> If you are behind those growths, I would love to hear more details: technology used, issues, …
>

Gepff

For those who haven't seen it, Akamai also launched some similar reporting
today
based on a cross-section of dual-stacked customer content:

http://www.stateoftheinternet.com/ipv6

This also shows the US crossing 10% as well as the same impressive
growth in those European countries.

Malaysia and Japan are also on-track to getting reliably into the 5% club
soon.
Ecuador (looks like CNT Ecuador) and Bosnia/Herzegovina also have had
recent jumps.

Erik



On Mon, Nov 3, 2014 at 2:43 AM, Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> [.As a side note, it seems that the European 'google' statistics are now
> more in line with the expectation]
>
> Several countries have recently made good progress dixit Google & Apnic
> (URL are simply a different way of presenting Google data):
>
> - US has reached 10%, welcome to the 10%-club
> - Estonia has a VERY impressive growth approaching 5%:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
> - Other European countries with a recent growth:
> - Austria:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
> - Czech republic:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=cz
> - Norway:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=no
> - Greece:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr
> - Portugal:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=pt
>
> If you are behind those growths, I would love to hear more details:
> technology used, issues, …
>
> Congratulations anyway
>
> -éric
>

Estonia's growth from a customers point of view - no relations with ISP -
Estonia's main ISP Elion (part of Teliasonera) has been using Inteno DG301
as endpoints for a few months now and dual-stack is now being enabled on
them.

2014-11-03 17:26 GMT+02:00 Erik Nygren <erik@nygren.org>:

> For those who haven't seen it, Akamai also launched some similar reporting
> today
> based on a cross-section of dual-stacked customer content:
>
> http://www.stateoftheinternet.com/ipv6
>
> This also shows the US crossing 10% as well as the same impressive
> growth in those European countries.
>
> Malaysia and Japan are also on-track to getting reliably into the 5% club
> soon.
> Ecuador (looks like CNT Ecuador) and Bosnia/Herzegovina also have had
> recent jumps.
>
> Erik
>
>
>
> On Mon, Nov 3, 2014 at 2:43 AM, Eric Vyncke (evyncke) <evyncke@cisco.com>
> wrote:
>
>> [.As a side note, it seems that the European 'google' statistics are now
>> more in line with the expectation]
>>
>> Several countries have recently made good progress dixit Google & Apnic
>> (URL are simply a different way of presenting Google data):
>>
>> - US has reached 10%, welcome to the 10%-club
>> - Estonia has a VERY impressive growth approaching 5%:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
>> - Other European countries with a recent growth:
>> - Austria:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
>> - Czech republic:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=cz
>> - Norway:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=no
>> - Greece:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr
>> - Portugal:
>> https://www.vyncke.org/ipv6status/plotpenetration.php?country=pt
>>
>> If you are behind those growths, I would love to hear more details:
>> technology used, issues, ...
>>
>> Congratulations anyway
>>
>> -éric
>>
>
>


--

Tervitades,

Jaanus Jõgisu
jogisu@gmail.com

hey,

> Estonia has a VERY impressive growth approaching 5%:
> https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee

I have been driving an IPv6 project in Elion (now called Estonian
Telekom) for some time now and this is the result. One of the goals I
set for myself was exactly such aggressive result.

We have enabled native v6 for all our users and everyone with suitable
last-gen CPE can use it automatically.

I will do technical writeup on the tech we are using after we get our PR
out (which should be soon).

--
tarko

On Tuesday, November 04, 2014 09:52:43 AM Tarko Tikan wrote:

> I will do technical writeup on the tech we are using
> after we get our PR out (which should be soon).

That would be awesome.

For consumer broadband deployments, it would be nice to know
what technologies you and others have gone with for
subscriber management, e.g., DHCP vs. PPPoE, ND/RA vs. DHCP
IA_NA, e.t.c.

Cheers,

Mark.

"Eric Vyncke (evyncke)" <evyncke@cisco.com> writes:

> * Norway: https://www.vyncke.org/ipv6status/plotpenetration.php?country=no
..
> If you are behind those growths, I would love to hear more details: technology used, issues, …

As others have stated, the growth in Norway is caused by an increase in
the number of Telenor retail ADSL, VDSL and GPON customers with native
dual stack access.

Erik has already provided some details on the CPE side. So I will try
to add a bit of network details.

The L2 access network is as stated: a mix of xDSL and GPON.

We do use PPPoE for some IPv4 xDSL accesses, but for IPv6 it has been
decided to only support IPoE. So the PPPoE support remains IPv4 only
(for now at least - I'm not going to predict the future here).

The IP "sessions" are terminated on Juniper MX access servers (BNGs or
whatever), which also function as DHCP and DHCPv6 servers. The DHCPv6
server will hand out a single IA_NA address dynamically allocated [1]
from a pool local to the access server, and a single IA_PD prefix
statically allocated to the user. The local DHCPv6 server use a RADIUS
backend for the per-user static configuration. The users are identified
by an DHCPv6 Relay Agent Remote-ID being added by the DSLAM or OLT,
functioning as an RFC6221 Lightweight DHCPv6 Relay Agent.

We have not committed to any fixed policy for the retail user IA_PD
prefixes. They are currently /48s, aggregated on /36 boundaries [2] on
the access servers. Which means that the prefix is changed if the user
switches to another access server. Typically only when physically
moving, but might also happen due to changes in the access network
topology. For most users the prefix will remain the same "forever".
It's just not guaranteed anywhere. Note that this also goes for the
prefix length, although I don't currently see any valid reason to change
that.

Business users use the exact same infrastructure, but their prefixes are
not aggregated by the access servers. This allows them to be truly
static from a technical point of view. The actual policy will probably
depend on the specific product/agreement. I don't know anything about
that.

A default IPv6 route is announced by the MXes using RAs with no prefix
option. I.e. there are no on-link prefixes on the WAN link. Which is
logical for an ISP access network. Users on different links are not
supposed to talk to each other on L2.

We do not support reverse DNS for retail users at the moment.

There have of course been a gazillion minor issues. I don't even
remember a fraction of them. Some of it has been related IPv6 multicast,
filtering and DHCPv6 relaying support in the L2 access network. This is
still a grey area, requiring hardware replacements to be 100% complete.

There are lots of details, so please ask if you are missing some
specific information...


[1] The IA_NA address is mainly intended for CPE management purposes,
which is why it doesn't matter that it changes for each DHCPv6
session.

[2] access servers with more than 4096 users aggregate on multiple /36s
Using as few prefix lengths as possible and cutting on nibble
boundaries are deliberate strategies to simplify address management
Thanks to lazy developers :-)



Bjørn (lazy Telenor developer)

On Tuesday, November 04, 2014 02:27:03 PM Bjørn Mork wrote:

> Erik has already provided some details on the CPE side.
> So I will try to add a bit of network details.

Very nice, Bjorn. Thanks!

Mark.

On 11/03/2014 10:25 AM, Geoff Huston wrote:
>> On 3 Nov 2014, at 6:43 pm, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
>>
>> [.As a side note, it seems that the European 'google' statistics are now more in line with the expectation]
>>
>> Several countries have recently made good progress dixit Google & Apnic (URL are simply a different way of presenting Google data):
>> • US has reached 10%, welcome to the 10%-club
>> • Estonia has a VERY impressive growth approaching 5%: https://www.vyncke.org/ipv6status/plotpenetration.php?country=ee
>> • Other European countries with a recent growth:
>> • Austria: https://www.vyncke.org/ipv6status/plotpenetration.php?country=at
>>
>> • Greece: https://www.vyncke.org/ipv6status/plotpenetration.php?country=gr
> Hellenic Telecommunications: http://stats.labs.apnic.net/ipv6/AS6799?a=6799&c=GR&x=1&s=1&p=1&w=1&s=0

the short story here is that we're (finally) enabling IPv6 on our
(already capable) CPEs :)

>> If you are behind those growths, I would love to hear more details: technology used, issues, …
>>
> Gepff
>
>

On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
[..]
> the short story here is that we're (finally) enabling IPv6 on our
> (already capable) CPEs :)

And then getting broken connectivity to Google:

https://www.sixxs.net/forum/?msg=general-12626989
https://forums.he.net/index.php?topic=3281.0

They used to have a useful ipv6@google.com address, seems that went
missing somewhere.

Greets,
Jeroen

* Jeroen Massar

> On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
> [..]
> > the short story here is that we're (finally) enabling IPv6 on our
> > (already capable) CPEs :)
>
> And then getting broken connectivity to Google:
>
> https://www.sixxs.net/forum/?msg=general-12626989
> https://forums.he.net/index.php?topic=3281.0

Non sequitur. I'd be extremely interesting in understanding how Yannis'
IPv6 deployment in OTE (kudos!) could possibly impact the SixXS/HE
tunnel users' ability to contact Google.

Anyway. Tunnels suck, news at 11... I wonder if QUIC will exacerbate the
problem, with no TCP MSS equivalent to help hide defective PMTUD.

https://ripe69.ripe.net/archives/video/10108/

Tore

On 2014-11-08 11:34, Tore Anderson wrote:
> * Jeroen Massar
>
>> On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
>> [..]
>>> the short story here is that we're (finally) enabling IPv6 on our
>>> (already capable) CPEs :)
>>
>> And then getting broken connectivity to Google:
>>
>> https://www.sixxs.net/forum/?msg=general-12626989
>> https://forums.he.net/index.php?topic=3281.0
>
> Non sequitur. I'd be extremely interesting in understanding how Yannis'
> IPv6 deployment in OTE (kudos!) could possibly impact the SixXS/HE
> tunnel users' ability to contact Google.

That is not what I wrote or intended.

Something unrelated to their deployment broke. But doing the deployment
does mean that you are now providing connectivity that breaks to two
major providers: Google and Akamai.

> Anyway. Tunnels suck, news at 11... I wonder if QUIC will exacerbate the
> problem, with no TCP MSS equivalent to help hide defective PMTUD.

Tunnels do not suck, people who have broken clusters that randomly drop
packets suck. Note that even with a full 1500 MTU you will have broken
connectivity to Google at the moment, lots of fun thus for those native
deployments like Unitymedia who forcefully stuff folks in DSlite land.

Currently that is both Akamai and Google. Both of which have been
working for a long long time.

At least Akamai is claiming to be looking into it, but with their recent
multiple Location: header fiasco I think they have more on their plate.

Note that this broken connectivity just gives a "Disable IPv6" cry from
a lot of people, which is a really bad thing.

Greets,
Jeroen

* Jeroen Massar

> On 2014-11-08 11:34, Tore Anderson wrote:
> > * Jeroen Massar
> >
> >> On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
> >> [..]
> >>> the short story here is that we're (finally) enabling IPv6 on our
> >>> (already capable) CPEs :)
> >>
> >> And then getting broken connectivity to Google:
> >>
> >> https://www.sixxs.net/forum/?msg=general-12626989
> >> https://forums.he.net/index.php?topic=3281.0
> >
> > Non sequitur. I'd be extremely interesting in understanding how
> > Yannis' IPv6 deployment in OTE (kudos!) could possibly impact the
> > SixXS/HE tunnel users' ability to contact Google.
>
> That is not what I wrote or intended.
>
> Something unrelated to their deployment broke. But doing the
> deployment does mean that you are now providing connectivity that
> breaks to two major providers: Google and Akamai.

I still do not follow. Is (or were) OTE's deployment broken? If
yes, is the reason for the brokenness the same as for the SixXS/HE
users? (Is OTE using 6RD?) If no, what is the connection between OTE's
deployment and the SixXS/HE problems you linked to?

> Tunnels do not suck, people who have broken clusters that randomly
> drop packets suck.

Let me rephrase: PMTUD sucks. Tunnels suck by association, because
they rely on PMTUD not sucking.

(Except where the tunnel can accomodate an inner MTU of 1500.)

> Note that even with a full 1500 MTU you will have
> broken connectivity to Google at the moment, lots of fun thus for
> those native deployments like Unitymedia who forcefully stuff folks
> in DSlite land.

This is news to me, both Google and Akamai works just fine from here
in Norway. Could you elaborate on what broke and how I could try to
reproduce it?

Tore

On 2014-11-08 16:16, Tore Anderson wrote:
> * Jeroen Massar
>
>> On 2014-11-08 11:34, Tore Anderson wrote:
>>> * Jeroen Massar
>>>
>>>> On 2014-11-08 10:27, Yannis Nikolopoulos wrote:
>>>> [..]
>>>>> the short story here is that we're (finally) enabling IPv6 on our
>>>>> (already capable) CPEs :)
>>>>
>>>> And then getting broken connectivity to Google:
>>>>
>>>> https://www.sixxs.net/forum/?msg=general-12626989
>>>> https://forums.he.net/index.php?topic=3281.0
>>>
>>> Non sequitur. I'd be extremely interesting in understanding how
>>> Yannis' IPv6 deployment in OTE (kudos!) could possibly impact the
>>> SixXS/HE tunnel users' ability to contact Google.
>>
>> That is not what I wrote or intended.
>>
>> Something unrelated to their deployment broke. But doing the
>> deployment does mean that you are now providing connectivity that
>> breaks to two major providers: Google and Akamai.
>
> I still do not follow. Is (or were) OTE's deployment broken?

No.

But their deployment, just like that of anybody else, will cause them to
make Google/Akamai unreachable or at least lag in the browser of the
people that any provider

> If
> yes, is the reason for the brokenness the same as for the SixXS/HE
> users? (Is OTE using 6RD?) If no, what is the connection between OTE's
> deployment and the SixXS/HE problems you linked to?

The only link: they are all using IPv6.

You are trying to make this OTE link. I have never stated anything like
that. Though, you likely take that from the fact that the reply followed
in that thread.

>> Tunnels do not suck, people who have broken clusters that randomly
>> drop packets suck.
>
> Let me rephrase: PMTUD sucks. Tunnels suck by association, because
> they rely on PMTUD not sucking.

No. PMTUD is fine.

What sucks is 'consultants' advising blocking ICMPv6 "because that is
what we do in IPv4" and that some hardware/software gets broken once in
a while.

> (Except where the tunnel can accomodate an inner MTU of 1500.)

That is irrelevant.

And likely in the case of Akamai it has little to do with MTU, just
nodes that hang and never reply as Wireshark shows an ongoing TCP
conversation, but that is just a guess.

>> Note that even with a full 1500 MTU you will have
>> broken connectivity to Google at the moment, lots of fun thus for
>> those native deployments like Unitymedia who forcefully stuff folks
>> in DSlite land.
>
> This is news to me, both Google and Akamai works just fine from here
> in Norway. Could you elaborate on what broke and how I could try to
> reproduce it?

See the threads I referenced, they are still in the above quoted text.

Note that the Google case is consistent: (as good as) every IPv6
connection breaks.

The Akamai case is random: sometimes it just works as you hit good nodes
in the cluster, sometimes it breaks.

In both cases, it is hard to say what exactly breaks as only the people
in those networks/companies have access to their side of the view.

As such... here is for hoping they debug and resolve the problem.

Greets,
Jeroen

* Jeroen Massar

> The only link: they are all using IPv6.
>
> You are trying to make this OTE link. I have never stated anything
> like that. Though, you likely take that from the fact that the reply
> followed in that thread.

Yannis: «We're enabling IPv6 on our CPEs»
Jeroen: «And then getting broken connectivity to Google»

I'm not a native speaker of English, but I struggle to understand it
any other way than you're saying there's something broken about
Yannis' deployment. I mean, your reply wasn't even a standalone
statement, but a continuation of Yannis' sentence. :-P

Anyway, I'm relieved to hear that there's no reason to supect IPv6
breakage in OTE. As we host a couple of the top-10 Greek sites, one of
which has IPv6, we're dependent on the big Greek eyeball network like
OTE to not screw up their IPv6 deployment - it is *I* who get in trouble
if they do. :-)

> PMTUD is fine.
>
> What sucks is 'consultants' advising blocking ICMPv6 "because that is
> what we do in IPv4" and that some hardware/software gets broken once
> in a while.

PMTUD is just as broken in IPv4, too. PMTUD has *never* been «fine»,
neither for IPv4 nor for IPv6. That's why everyone who provides links
with MTUs < 1500 resorts to workarounds such as TCP MSS clamping and
reducing MTU values in LAN-side RAs, so that reliance on PMTUD
working is limited as much as possible. If you want to deliver an
acceptable service (either as an ISP or as a content hoster), you just
*can't* depend on PMTUD.

Even when PMTUD actually works as designed it sucks, as it causes
latency before data may be successfully transmitted.

> See the threads I referenced, they are still in the above quoted text.
>
> Note that the Google case is consistent: (as good as) every IPv6
> connection breaks.
>
> The Akamai case is random: sometimes it just works as you hit good
> nodes in the cluster, sometimes it breaks.

I see in the threads referenced things statements such as:

«this must be a major issue for everybody using IPv6 tunnels»
«MTU 1480 MSS 1220 = fix»
«the 1480MTU and 1220MSS numbers worked for my pfsense firewall»
«The only thing that worked here is 1280 MTU / 1220 MSS»
«clamping the MSS to 1220 seems to have fixed the problem for me»
«I changed the MSS setting [...] for the moment Google pages are
loading much better»

This is all perfectly consistent with common PMTUD mailfunctioning /
tunnel suckage. I'm therefore very sceptical that this problem would
also be experienced by users with 1500 byte MTU links. (Assuming
there's only a single problem at play here.)

> In both cases, it is hard to say what exactly breaks as only the
> people in those networks/companies have access to their side of the
> view.
>
> As such... here is for hoping they debug and resolve the problem.

Having some impacted users do a Netalyzr test might be a good start.
Like I said earlier, WFM, but then again I'm not using any tunnels.

Tore

> On Nov 8, 2014, at 06:45, Jeroen Massar <jeroen@massar.ch> wrote:
>
>> On 2014-11-08 11:34, Tore Anderson wrote:
>> * Jeroen Massar
>


[clip]

> At least Akamai is claiming to be looking into it, but with their recent


We are. Including observing the discussion here and other places. I'll circle back with Erik and see if we have any thoughts we can share.


> multiple Location: header fiasco I think they have more on their plate.


That was a config error related to a single domain AFAIK. Thanks for noticing that. Appreciated.


Best,

-M<

> Including observing the discussion here and other places

I see the google problem discussed elsewhere too, perhaps the same
problem as -

----- Begin Included Message -----
From outages-bounces@outages.org Sat Nov 8 21:03:08 2014
Date: Sat, 8 Nov 2014 13:02:50 -0800
To: Mark Kamichoff <prox@prolixium.com>
Cc: outages@outages.org, Joe Hamelin <joe@nethead.com>
Subject: Re: [outages] fonts.gstatic.com IPv6 issues...
From: "Aaron C. de Bruyn via Outages" <outages@outages.org>
Reply-To: "Aaron C. de Bruyn" <aaron@heyaaron.com>
Sender: "Outages" <outages-bounces@outages.org>

Nice work Mark!

It only started for me about a week ago. I've had my HE tunnel for years.
I wonder if they just enabled IPv6 service to that particular web property,
or if they made a recent config change.
Anyways, I wonder if someone from Google reads the outages list, or if
NANOG should be CC'd to get their attention.

On Sat, Nov 8, 2014 at 11:26 AM, Mark Kamichoff via Outages <
outages@outages.org> wrote:

> On Sat, Nov 08, 2014 at 08:07:56AM -0500, Stephen Frost via Outages wrote:
> > I've been having issues w/ google IPv6 (more-or-less all services
> > operating over 80/443 have been really bad, though imap/993 has had
> > issues also) for at least 18 hours from a SixXS tunnel which terminates
> > in Ashburn.
>
> "me too" (I'm in Seattle, USA)
>
> I've narrowed down this issue to Google ignoring ICMPv6 PTBs. It
> sometimes works sporadically for me, though. Here's an example w/some
> tcpdumps:
>
> http://www.prolixium.com/share/txt/google-ipv6-pmtud-fail.txt
>
> Relevant lines are the following:
>
> 13:51:34.046171 IP6 2001:48c8:1:2::2 > 2607:f8b0:4005:802::1006: ICMP6,
> packet too big, mtu 1280, length 1240
> 13:51:34.562579 IP6 2607:f8b0:4005:802::1006.443 >
> 2001:48c8:1:105:21c:c0ff:feb2:8dbd.33936: Flags [.], seq 1:1429, ack
> 279, win 232, options [nop,nop,TS val 3392471676 ecr 756572814], length
> 1428
>
> Google never lowers the packet length and so the connection times out.
> As others have mentioned, this only really affects tunneled users.
>
> I've seen other organizations break this over the years but I never
> thought Google would make the list..
>
> - Mark
>
> --
> Mark Kamichoff
> prox@prolixium.com
> http://www.prolixium.com/
>
> _______________________________________________
> Outages mailing list
> Outages@outages.org
> https://puck.nether.net/mailman/listinfo/outages
>
>
----- End Included Message -----

hey,

> That would be awesome.
>
> For consumer broadband deployments, it would be nice to know
> what technologies you and others have gone with for
> subscriber management, e.g., DHCP vs. PPPoE, ND/RA vs. DHCP
> IA_NA, e.t.c.

I promised to do it and I have done it while it's still 2014 :) Check
the "Estonian IPv6 deployment report" thread.

--
tarko