IPv6 Intelligence – MrLooquer

Please, allow us to introduce MrLooquer -> https://www.mrlooquer.com


MrLooquer combines open source intelligence techniques with heuristic and data mining to perform one of the first attempts to create a real map about

IPv6 deployment and its relationship with current networks and protocols.


MrLooquer is born as an open initiative with Creative Commons license focused on:

– Data discovery

– Visual intelligence

– Relationship


Our main goal is to provide a useful tool for security analysts around the world. MrLooquer allows users to make advanced queries through our big data infrastructure to obtain datasets with relationships between domains, IPv4, IPv6, service informations, geolocation, etc…


We’ve released the first version recently. It’s just the bread and butter… We are developing a roadmap that includes, among other things,  threat indicator based on relationships and patterns.


Please, feel free to start using it and we would be thankful for any type of feedback.


Best regards,

MrLooquer team.


Web: https://www.mrlooquer.com

Twitter: https://twitter.com/mrlooquer

Blog: http://blog.mrlooquer.com/

IPv6 HSRP Config

Interface vlan777

ipv6 enable



Otherwise, the config looks spot on


Our config looks like:


interface Vlan110

standby version 2

standby 110 ipv6 FE80::1

standby 110 timers 1 3

standby 110 priority 110

standby 110 preempt delay minimum 180

standby 110 authentication xxxx

ipv6 address dead:beef:1::FFFE/64

ipv6 enable

ipv6 nd other-config-flag

ipv6 nd router-preference High

ipv6 pim dr-priority 4294967295

ipv6 dhcp relay destination dead:beef:0::1

ipv6 dhcp relay destination dead:beef:0::2

IPv6 : Win7 vs Win8

Just an update: I eyeballed the “PrefixPolicies-Vista78.cmd” script from

https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded

that it was safe, and ran it. It apparently works, but I don’t have a

ULA setup to test it with.

jrey42 deserves kudos.



On 21/12/2015 07:57, Brian E Carpenter wrote:

On 21/12/2015 03:28, Marc Luethi wrote:

Hi all

I suggest to investigate source address selection on the client side,

while closely following name resolution (assuming this is similar to

Windows 2012R2’s DA implementation, DNS64 is supposed to be at work, here)

and keeping an eye on the IPv6 routing table.

In your situation, I would presume that the end system ends up with an RFC

4193 address (from the /48 that was initially chosen when DA was set up) on

its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)

and a global unicast address  the (W)LAN interface, based on the CPE’s RAs.

While things *should* be neat, my experience with Windows 7’s way of

picking source addresses was so bad (“longest match” seemed entirely

unheard-of), I eventually gave up using RFC 4193 addresses for my internal

network altogether.

I repeateadely observed Win7 using its global unicast address(es) to access

internal ressources, while stubbornly sticking to te RFC4193 source address

when attempting to talk to addresses on the global IPv6 internet.

Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not

RFC3484). It would be possible to make Win8 misbehave by changing the default

preferences (https://tools.ietf.org/html/rfc6724#section-10.6).

Conversely, it’s possible to make Win7 behave correctly by changing its default

policies to conform to RFC6724. I just found the following site that offers a

script (YMMV, I haven’t checked it):


But if that is the cause of the original issue, maybe switching off the

ULA prefix would be easier, and nicer than switching off IPv6.

     Brian Carpenter



On 19 December 2015 at 22:37, Kurt Buff  wrote:


I ran into an interesting situation some months ago which still

baffles me, and though I was able to work around it, I expect it will

happen again.

We implemented MSFT DirectAcess at our company quite some time ago

(using 2008R2 and Forefront 2010), and it works extremely well.

At least it worked well for everyone until one of the employees got

his Comcast connection upgraded, and then DirectAccess didn’t work for

that employee any more.

We proved that if he tethered to his cell phone, that would work, and

if he used an SSL VPN client while on his Comcast connect that would

work, but DirectAccess would not work at home.

Finally, I discovered that his Comcast-installed router was handing

our IPv6 addresses on his home LAN. Turning that off enabled

DirectAccess to work again.

We do not have an assigned IPv6 block from our ISP, though of course

MSFT OSes use it, and auto-assign themselves addresses, but for now

we’re ignoring it.

Has anyone run into this problem and solved it – not by turning off

iIPv6 address assignment for the home LAN, but really solved it? If

so, how did you do that?

Would getting and implementing an IPv6 assignment from our ISP cure

the problem, or make it worse?

I’ve found little guidance from MSFT about DirectAccess in an IPv6

environment, though I admit I haven’t been terribly diligent in my



Windows NIC/driver issues with IPV6 TCP checksum offloading


Two suspect NICs at this point:  

– Intel® 82579LM found in some HP laptops.   Disabling the IPV6 TCP checksum offloading resolves the problem.  

– Realtek RTL8111E – The problem is inconsistent  

Since rolling out dual-stack IPV6 to our consumer Internet customers, we’ve had a couple of customer incidents with very slow IPV6 TCP performance to dual-stacked websites (facebook, Wikipedia.org, …).   The problems only occurs with Windows 7/8/10 PCs connected via Ethernet NICs.   Disabling IPV6 TCP checksum offloading will resolve the performance issues in some cases, but not in all cases.   We have tried updating the Windows NIC driver to the latest version, but that didn’t help.   I’m wondering if anybody else has seen this issue with Windows PCs. 

Google no longer returning AAAA records?

For the avoidance of mystery: Google performs measurements of IPv6 connectivity and latency on an ongoing basis. The Google DNS servers do not return AAAA records to DNS resolvers if our measurements indicate that for users of those resolvers, HTTP/HTTPS access to dual-stack Google services is substantially worse than to equivalent IPv4-only services. “Worse” covers both reliability (e.g., failure to load a URL) and latency (e.g., IPv6 is 100ms worse than IPv4 because it goes over an ocean). The resolvers must also have a minimum query volume, which is fairly low.


I suggest checking if any of your affected users have broken 6to4 setups,
and that you are applying the relevant mitigations in RFC 6343.

MTU size issues and high latency have also both been mentioned as
possible reasons for the mysterious AAAA blacklist.



Netflow – FNF cheat sheet

Here’s a quick basic FNF (from ASR 1000):

flow exporter PRIMARY_NMS
 description FNF export to Primary NMS
 source Loopback0
 transport udp 9996
 template data timeout 60
flow monitor MONITOR_V4
 description IPv4 netflow monitor
 record netflow ipv4 original-input
 exporter PRIMARY_NMS
 cache timeout active 900
 cache entries 200000
flow monitor MONITOR_V6
 description IPv6 netflow monitor
 record netflow ipv6 original-input
 exporter PRIMARY_NMS
 cache timeout active 900
 cache entries 200000
!For each interface ....
interface GigabitEthernet0/0/0
 ip flow monitor MONITOR_V4 input
 ipv6 flow monitor MONITOR_V6 input
interface GigabitEthernet1/0/0
 ip flow monitor MONITOR_V4 input
 ipv6 flow monitor MONITOR_V6 input

IPv6 funny words




1 2