Free.fr vs HE.net IPv6 (Was: CISA: Guidance on the Essential Critical Infrastructure Workforce)

[Radu-Adrian Feurdean]

On Sat, Mar 28, 2020, at 19:52, Mike Hammett wrote:
> https://radar.qrator.net/as12322/providers#startDate=2019-12-27=2020-03-27=current

Did you read the part about *IPv6* traffic ?
Your link points to some IPv*4* relationship. Over IPv6, you get this :

https://radar.qrator.net/as12322/ipv6-providers#startDate=2019-12-29=2020-03-29=current

Note the "Active Now" part, which is only active for Cogent.

And then, rather than taking QRator (which does a good job and has interesting 
information on a number of things - who buys transit from who *NOT* being one 
of those things - or at least not the public information) as word of absolute 
truth, did you test that bgp.he.net thinks about this ? Since HE is one of the 
parties, it does make sense to check their tools to see their point of view.

Long story short:
 - Free.fr in known in France (where I happen to live and work) for only having 
Cogent as a transit for the last few years.
 - they are also known to peer (like "only exchange own routes and customer 
routes") with some "very big" networks (usually called "tier-1") : level3 and 
zayo among them.
 - Cogent and HE over IPv6 ... I suppose everybody knows the story.
 - Free.fr depeered he.net about one week ago...

There have been some exchanges of tentative traceroutes in both directions on 
FRnOG (French NOG) and things are clear : free.fr and he.net cannot exchange 
IPv6 traffic.

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/28/2020 5:35 PM, Ragnar Sundblad wrote:
> 
> 
>> On 29 Mar 2020, at 01:18, Harlan Stenn  wrote:
>>
>> Ragnar,
>>
>> On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
>>>
>>>
 On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:

 Ragnar,

 On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>
>> On 28 Mar 2020, at 23:58, Harlan Stenn  wrote:
>>
>>> Steven Sommars said:
 The secure time transfer of NTS was designed to avoid
>>>  amplification attacks.
>>
>> Uh, no.
>
> Yes, it was.
>
> As Steven said, “The secure time transfer of NTS was designed to
> avoid amplification attacks”. I would even say - to make it
> impossible to use for amplification attacks.

 Please tell me how.  I've been part of this specific topic since the
 original NTS spec.  For what y'all are saying to be true, there are some
 underlying assumptions that would need to be in place, and they are
 clearly not in place now and won't be until people update their
 software, and even better, tweak their configs.
>>>
>>> The NTS protected NTP request is always of the same size, or in some
>>> cases larger, than the NTS protected NTP response. It is carefully
>>> designed to work that way.
>>
>> So what?
>>
>> The use of NTS is completely independent of whether or not a server will
>> respond to a packet.
>>
>> And an unauthenticated NTP request that generates an unauthenticated
>> response is *always* smaller than an authenticated request, regardless
>> of whether or not the server responds.
>>
>> Claiming that amplification is a significant issue in the case where
>> there's no amplification but the base packet size is bigger is ignoring
>> a key piece of information, and is disingenuous in my book.
> 
> You are now comparing unauthenticated mode 3 and mode 4 packets to
> cryptographically secured ones, which is a completely different thing.
> 
> Disingenuous?

I made no such claim.

I was talking about:

> As Steven said, “The secure time transfer of NTS was designed to
> avoid amplification attacks”. I would even say - to make it
> impossible to use for amplification attacks.

and that statement is not as clear as it could be.  Specifically:

 NTS was designed to avoid amplification attacks

is vague.

You have just now written:

> You are now comparing unauthenticated mode 3 and mode 4 packets to
> cryptographically secured ones, which is a completely different thing.

Completely different?  How?

Where is the amplification in an unauthenticated mode 3 request and an
unauthenticated response?

How does cryptographically securing these packets make any difference here?

> A protocol with varying packet size, as the NTS protected NTP is,
> can easily have the bad property of having responses larger than the
> requests if not taken care. Don’t you see that?

I sure think I understand these points.

Who here has said that there was any problem with there being an
amplification issue with properly-authenticated NTS packets?

The current NTS spec is *only* written for mode 3/4 exchanges.  While it
might be applicable for mode 6/7, I haven't seen any specs for this
usage.  In the NTP Project's Reference implementation there are extra
implementation-specific protections built in to mode 6/7 exchanges.
While some of this might be addressed in the NTS spec, I don't recall
ever seeing this.

So why are you talking about mode 6/7 in this context?

>>> Hence, [what Steven said].
>>>
>> If you understand what's going on from the perspective of both the
>> client and the server and think about the various cases, I think you'll
>> see what I mean.
>
> Hopefully, no-one exposes mode 6 or mode 7 on the internet anymore
> at least not unauthenticated, and at least not the commands that are
> not safe from amplification attacks. Those just can not be allowed
> to be used anonymously.

 But mode 6/7 is completely independent of NTS.
>>>
>>> Exactly. No one needs to, or should, expose mode6/7 at all. They were
>>> designed at a time when the internet was thought to be nice place were
>>> people behaved, decades ago, today they are just huge pains in the
>>> rear. Sadly allowing anonymous mode 6/7 was left in there far to long
>>> (admittedly being wise in hindsight is so much easier than in advance).
>>> And here we are, with UDP port 123 still being abused by the bad
>>> guys, and still being filtered by the networks.
>>
>> Your statement about "exposing" is imprecise and bordering on incorrect,
>> at least in some cases.
> 
> Exposing to the Internet, or anyone but the system owner.

I think you're in the right ballpark, but the edges of your boundaries
are a bit off.

> I just can’t imagine that you didn’t fully understand that.

I think I have a pretty wide and deep understanding of these issues.

If I'm correct, then perhaps we are simply communicating imprecisely.

If I'm missing something, I'd like to know 

Re: UDP/123 policers & status

[Harlan Stenn]

I think I see the disconnect.

One of the design goals of NTS was to prevent NTS-protected time
requests from being used in amplification attacks.  Yes, that's true.

I've been interpreting this thread as people claiming that NTS will
solve a wider class of amplification vectors, and that's simply not true.

"Universal affirmatives can only be partially converted: all of Alma
Cogen is dead, but only some of the class of dead people are Alma Cogen."

It's also true, and generally not stated, that to the extent that
NTS-protected packets are exchanged, they will require increased network
capacity.  A cynic could argue that requiring additional internet
bandwidth is a profitable goal, and the drama about requiring that extra
protection is the distraction that normalizes that cost.

H

On 3/28/2020 5:18 PM, Harlan Stenn wrote:
> Ragnar,
> 
> On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
>>
>>
>>> On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:
>>>
>>> Ragnar,
>>>
>>> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:

> On 28 Mar 2020, at 23:58, Harlan Stenn  wrote:
>
>> Steven Sommars said:
>>> The secure time transfer of NTS was designed to avoid
>>   amplification attacks.
>
> Uh, no.

 Yes, it was.

 As Steven said, “The secure time transfer of NTS was designed to
 avoid amplification attacks”. I would even say - to make it
 impossible to use for amplification attacks.
>>>
>>> Please tell me how.  I've been part of this specific topic since the
>>> original NTS spec.  For what y'all are saying to be true, there are some
>>> underlying assumptions that would need to be in place, and they are
>>> clearly not in place now and won't be until people update their
>>> software, and even better, tweak their configs.
>>
>> The NTS protected NTP request is always of the same size, or in some
>> cases larger, than the NTS protected NTP response. It is carefully
>> designed to work that way.
> 
> So what?
> 
> The use of NTS is completely independent of whether or not a server will
> respond to a packet.
> 
> And an unauthenticated NTP request that generates an unauthenticated
> response is *always* smaller than an authenticated request, regardless
> of whether or not the server responds.
> 
> Claiming that amplification is a significant issue in the case where
> there's no amplification but the base packet size is bigger is ignoring
> a key piece of information, and is disingenuous in my book.
> 
>> Hence, [what Steven said].
>>
> If you understand what's going on from the perspective of both the
> client and the server and think about the various cases, I think you'll
> see what I mean.

 Hopefully, no-one exposes mode 6 or mode 7 on the internet anymore
 at least not unauthenticated, and at least not the commands that are
 not safe from amplification attacks. Those just can not be allowed
 to be used anonymously.
>>>
>>> But mode 6/7 is completely independent of NTS.
>>
>> Exactly. No one needs to, or should, expose mode6/7 at all. They were
>> designed at a time when the internet was thought to be nice place were
>> people behaved, decades ago, today they are just huge pains in the
>> rear. Sadly allowing anonymous mode 6/7 was left in there far to long
>> (admittedly being wise in hindsight is so much easier than in advance).
>> And here we are, with UDP port 123 still being abused by the bad
>> guys, and still being filtered by the networks.
> 
> Your statement about "exposing" is imprecise and bordering on incorrect,
> at least in some cases.
> 
> But again, the use of mode 6/7 is completely independent of NTS.  You
> are trying to tie them together.
> 
> 
>>> It's disingenuous for people to imply otherwise.
>>
>> I couldn’t say, I don’t even know of an example of someone who does.
> 
> You've done it in two cases here, from everything I have seen.
> 
>> Ragnar
> 

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

Ragnar,

On 3/28/2020 4:59 PM, Ragnar Sundblad wrote:
> 
> 
>> On 29 Mar 2020, at 00:35, Harlan Stenn  wrote:
>>
>> Ragnar,
>>
>> On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
>>>
 On 28 Mar 2020, at 23:58, Harlan Stenn  wrote:

> Steven Sommars said:
>> The secure time transfer of NTS was designed to avoid
>   amplification attacks.

 Uh, no.
>>>
>>> Yes, it was.
>>>
>>> As Steven said, “The secure time transfer of NTS was designed to
>>> avoid amplification attacks”. I would even say - to make it
>>> impossible to use for amplification attacks.
>>
>> Please tell me how.  I've been part of this specific topic since the
>> original NTS spec.  For what y'all are saying to be true, there are some
>> underlying assumptions that would need to be in place, and they are
>> clearly not in place now and won't be until people update their
>> software, and even better, tweak their configs.
> 
> The NTS protected NTP request is always of the same size, or in some
> cases larger, than the NTS protected NTP response. It is carefully
> designed to work that way.

So what?

The use of NTS is completely independent of whether or not a server will
respond to a packet.

And an unauthenticated NTP request that generates an unauthenticated
response is *always* smaller than an authenticated request, regardless
of whether or not the server responds.

Claiming that amplification is a significant issue in the case where
there's no amplification but the base packet size is bigger is ignoring
a key piece of information, and is disingenuous in my book.

> Hence, [what Steven said].
> 
 If you understand what's going on from the perspective of both the
 client and the server and think about the various cases, I think you'll
 see what I mean.
>>>
>>> Hopefully, no-one exposes mode 6 or mode 7 on the internet anymore
>>> at least not unauthenticated, and at least not the commands that are
>>> not safe from amplification attacks. Those just can not be allowed
>>> to be used anonymously.
>>
>> But mode 6/7 is completely independent of NTS.
> 
> Exactly. No one needs to, or should, expose mode6/7 at all. They were
> designed at a time when the internet was thought to be nice place were
> people behaved, decades ago, today they are just huge pains in the
> rear. Sadly allowing anonymous mode 6/7 was left in there far to long
> (admittedly being wise in hindsight is so much easier than in advance).
> And here we are, with UDP port 123 still being abused by the bad
> guys, and still being filtered by the networks.

Your statement about "exposing" is imprecise and bordering on incorrect,
at least in some cases.

But again, the use of mode 6/7 is completely independent of NTS.  You
are trying to tie them together.


>> It's disingenuous for people to imply otherwise.
> 
> I couldn’t say, I don’t even know of an example of someone who does.

You've done it in two cases here, from everything I have seen.

> Ragnar

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

Ragnar,

On 3/28/2020 4:09 PM, Ragnar Sundblad wrote:
> 
>> On 28 Mar 2020, at 23:58, Harlan Stenn  wrote:
>>
>>> Steven Sommars said:
 The secure time transfer of NTS was designed to avoid
>>>amplification attacks.
>>
>> Uh, no.
> 
> Yes, it was.
> 
> As Steven said, “The secure time transfer of NTS was designed to
> avoid amplification attacks”. I would even say - to make it
> impossible to use for amplification attacks.

Please tell me how.  I've been part of this specific topic since the
original NTS spec.  For what y'all are saying to be true, there are some
underlying assumptions that would need to be in place, and they are
clearly not in place now and won't be until people update their
software, and even better, tweak their configs.

>> If you understand what's going on from the perspective of both the
>> client and the server and think about the various cases, I think you'll
>> see what I mean.
> 
> Hopefully, no-one exposes mode 6 or mode 7 on the internet anymore
> at least not unauthenticated, and at least not the commands that are
> not safe from amplification attacks. Those just can not be allowed
> to be used anonymously.

But mode 6/7 is completely independent of NTS.

It's disingenuous for people to imply otherwise.

>> NTS is a task-specific hammer.
> 
> Yes.
> 
> Ragnar

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Harlan Stenn]

On 3/28/2020 3:29 PM, Bottiger wrote:
> but why isn't BCP 38 widely deployed?  
> 
> 
> Because it costs time and money. People have been asking for it to be
> implemented for decades. It is never going to be deployed on every network.

So you are claiming BCP 38 has to be all or nothing?  That there is *no*
benefit to incremental deployment?

> What fraction of the
> world does implement BCP 38?  
> 
> 
>  Not enough. Everyone has to use it for it to work. Otherwise the
> hackers will still find a network that doesn't have it.

I disagree.  Enough people have to use it for it to work.  And as more
folks use it, there is increasing motivation for more folks to use it.
As the number of deployments increases, one can assume (perhaps
correctly) that it will become less expensive to deploy, and that
additional measures will be found to help accomplish the same thing.

> I'd also be interested in general background info on DDoS.  Who is
> DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor? 
> Bad guys making a test run to see if the server can be used for a
> real run?  
> 
> 
> Most motivations for attacks can't be traced. But this is not just a
> gaming problem. It is used to extort businesses for money, destroy
> competitors, shutdown government critics, fame. 
> 
>  Is DDoS software widely available on the dark web?
> 
> 
> You don't need the dark web. It is widely available on Github like most
> other attack types.
> 
> https://github.com/search?q=ntp+ddos  
> 
> Broken protocols need to be removed and blacklisted at every edge.
> Pushing the responsibility to BCP38 is unrealistic.

The monlist attack was mitigated many years' ago.  The problem is that
too many folks don't upgrade their software.

> On Mon, Mar 23, 2020 at 7:43 AM Hal Murray
>  > wrote:
> 
> Steven Sommars said:
> > The secure time transfer of NTS was designed to avoid
> amplification attacks.

Uh, no.

If you understand what's going on from the perspective of both the
client and the server and think about the various cases, I think you'll
see what I mean.

NTS is a task-specific hammer.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: UDP/123 policers & status

[Bottiger]

>
> but why isn't BCP 38 widely deployed?
>

Because it costs time and money. People have been asking for it to be
implemented for decades. It is never going to be deployed on every network.

What fraction of the
> world does implement BCP 38?
>

 Not enough. Everyone has to use it for it to work. Otherwise the hackers
will still find a network that doesn't have it.

I'd also be interested in general background info on DDoS.  Who is DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?


Most motivations for attacks can't be traced. But this is not just a gaming
problem. It is used to extort businesses for money, destroy competitors,
shutdown government critics, fame.

 Is DDoS software widely available on the dark web?


You don't need the dark web. It is widely available on Github like most
other attack types.

https://github.com/search?q=ntp+ddos

Broken protocols need to be removed and blacklisted at every edge. Pushing
the responsibility to BCP38 is unrealistic.


On Mon, Mar 23, 2020 at 7:43 AM Hal Murray <
hgm+na...@ip-64-139-1-69.sjc.megapath.net> wrote:

> Steven Sommars said:
> > The secure time transfer of NTS was designed to avoid amplification
> attacks.
>
> I work on NTP software (ntpsec).  I have a couple of low cost cloud
> servers in
> the pool where I can test things and collect data.
>
> I see bursts of 10K to several million packets "from" the same IP Address
> at
> 1K to 10K packets per second.  Ballpark of 100 events per day, depending
> on
> the size cutoff.  I saw one that lasted for most of a day at 1K
> packeets/sec.
>
> All the packets I've seen have been vanilla NTP requests - no attempt at
> amplification.  I'm only checking a very small fraction of the garbage.
>
> I haven't seen any pattern in the target IP Address.  Reverse DNS names
> that
> look like servers are rare.  I see legitimate NTP requests from some of
> the
> targets.
>
> Would data be useful?  If so, who, what, ... (poke me off list)
>
> I don't see any good solution that a NTP server can implement.  If I block
> them all, the victim can't get time.  If I let some fraction through, that
> just reduces the size of the DDoS.  I don't see a fraction that lets
> enough
> through so the victim is likely to get a response to a legitimate request
> without also getting a big chunk of garbage.  I'm currently using a
> fraction
> of 0.  If the victim is using several servers, one server getting knocked
> out
> shouldn't be a big deal.  (The pool mode of ntpd should drop that system
> and
> use DNS to get another.)
>
> If NTS is used, it would be possible to include the clients IP Address in
> the
> cookie and only respond to requests with cookies that were issued to the
> client.  That has privacy/tracking complications.
>
> --
>
> I don't want to start a flame war, but why isn't BCP 38 widely deployed?
> Can
> somebody give me a pointer to a talk at NANOG or such?  What fraction of
> the
> world does implement BCP 38?
>
> I'd also be interested in general background info on DDoS.  Who is
> DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?
> Is DDoS software widely available on the dark web?  ...
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>

Re: Studies of Internet Paths "QoS"

[Saku Ytti]

Hey,

> As a brief intro, I am in charge of Analytics/ML/AI as a Cisco Fellow. We 
> have been studying a number of paths characteristics through the Internet 
> both single and multi-SP, Best-effort/Business Internet backbone/MPLS, … 
> across all regions in the world and lately focussing on SaaS, going beyond 
> the traditional delay/loss/jitter but computing various statistical moments, 
> using stats/ML to detect trends/seasonality, path variances, etc … Such 
> studies are used to enhance our best path selection algorithms in various 
> contexts such as SD-WAN, … using reactive and predictive analytics.

What did you learn?

-- 
  ++ytti

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Mike Hammett]

https://radar.qrator.net/as12322/providers#startDate=2019-12-27=2020-03-27=current
 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Lukas Tribus"  
To: "Radu-Adrian Feurdean"  
Cc: "Laura via NANOG Eilers"  
Sent: Saturday, March 28, 2020 12:24:23 PM 
Subject: Re: CISA: Guidance on the Essential Critical Infrastructure Workforce 

Hello, 

On Sat, 28 Mar 2020 at 11:13, Radu-Adrian Feurdean 
 wrote: 
> 
> Are you talking about the same Free.fr that depeered HE a few days ago and 
> expects all IPv6(*) traffic from HE to arrive via their only transit - Cogent 
> ? 

Cogent is not their only transit; at the moment at least I see both v4 
and v6 prefixes perfectly reachable via 3356. 


-lukas 

Studies of Internet Paths "QoS"

[JP Vasseur (jvasseur) via NANOG]

Hi Team,

As a brief intro, I am in charge of Analytics/ML/AI as a Cisco Fellow. We have 
been studying a number of paths characteristics through the Internet both 
single and multi-SP, Best-effort/Business Internet backbone/MPLS, … across all 
regions in the world and lately focussing on SaaS, going beyond the traditional 
delay/loss/jitter but computing various statistical moments, using stats/ML to 
detect trends/seasonality, path variances, etc … Such studies are used to 
enhance our best path selection algorithms in various contexts such as SD-WAN, 
… using reactive and predictive analytics. 

If you’re interested by such studies and/or you are working on such topics, 
happy to get connected.

On another fronts, I’m happy to present our work in the area of ML/AI for 
Networking at some point.

Cheers.

JP.

FCC Ensures Americans Can Access Zoom and WebEx During COVID-19 Crisis

[Sean Donelan]

https://www.fcc.gov/document/fcc-ensures-americans-can-access-zoom-and-webex-during-covid-19-crisis-0

The Federal Communications Commission today issued a temporary waiver of 
its access arbitrage rules to Inteliquent, a telecommunications company
that carries traffic for two of the nation’s largest conference calling 
providers, Zoom Video Communications and Cisco WebEx. Absent today’s 
waiver from the FCC’s Wireline Competition Bureau, the massive increase in 
conference calls made by American consumers using Zoom and WebEx to work 
and attend classes from home during the COVID-19 pandemic would likely 
result in Inteliquent being deemed an “access-stimulating” carrier under
the FCC’s rules. This, in turn, would trigger financial responsibilities — 
namely significant cost increases — for Inteliquent that would impede its 
ability to serve these  conference calling companies.

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Lukas Tribus]

Hello,

On Sat, 28 Mar 2020 at 11:13, Radu-Adrian Feurdean
 wrote:
>
> Are you talking about the same Free.fr that depeered HE a few days ago and 
> expects all IPv6(*) traffic from HE to arrive via their only transit - Cogent 
> ?

Cogent is not their only transit; at the moment at least I see both v4
and v6 prefixes perfectly reachable via 3356.


-lukas

Re: UDP/123 policers & status

[Roland Dobbins]

On 21 Mar 2020, at 4:58, Hal Murray wrote:

I don't want to start a flame war, but why isn't BCP 38 widely 
deployed?  Can
somebody give me a pointer to a talk at NANOG or such?  What fraction 
of the

world does implement BCP 38?

I'd also be interested in general background info on DDoS.  Who is 
DDoS-ing
whom and/or why?  Is this gamers trying to get an advantage on a 
competitor?
Bad guys making a test run to see if the server can be used for a real 
run?

Is DDoS software widely available on the dark web?  ...


Answers to all of these questions are readily available via search 
engines, searching the archive of this and related listservs, searching 
the presentation archives of 
NANOG/RIPE/APRICOT/APNIC/AusNOG/NZNOG/LACNIC, et. al.  My archive of 
public presentations is available here:




These topics are well-understood and -documented, and a bit of research 
can help bring one up to speed on them pretty quickly.



Roland Dobbins 

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Baldur Norddahl]

That would only be a problem for people that single home to HE? I love HE
but like Cogent it is probably not smart to have them as a single provider
for IPv6.

On the other hand I am surprised that a french company can single home with
Cogent. My experience is that Cogent has insufficient connectivity in
Europe for that to be a good idea.

lør. 28. mar. 2020 11.14 skrev Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net>:

> On Sat, Mar 21, 2020, at 08:37, Bill Woodcock wrote:
>
> > And a giant thumbs up to Free, who are keeping my 10G broadband flying
>
> Are you talking about the same Free.fr that depeered HE a few days ago and
> expects all IPv6(*) traffic from HE to arrive via their only transit -
> Cogent ?
>
> (*) close to 100% of their fixed customers having IPv6 enabled to CPE
> level.
>

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Radu-Adrian Feurdean]

On Sat, Mar 21, 2020, at 08:37, Bill Woodcock wrote:

> And a giant thumbs up to Free, who are keeping my 10G broadband flying 

Are you talking about the same Free.fr that depeered HE a few days ago and 
expects all IPv6(*) traffic from HE to arrive via their only transit - Cogent ?

(*) close to 100% of their fixed customers having IPv6 enabled to CPE level.