#ICMP headers: a way to know the header size

4:51:09.535198 IP (tos 0x0, ttl 64, id 51679, offset 0, flags [none], proto ICMP (1), length 28) > ICMP echo request, id 33295, seq 1, length 8
14:51:09.537177 IP (tos 0x0, ttl 64, id 15512, offset 0, flags [none], proto ICMP (1), length 28) > ICMP echo reply, id 33295, seq 1, length 8
lucafrancesca@tardis ~> ping -s 0 nas
PING nas.lab.local ( 0 data bytes
8 bytes from icmp_seq=0 ttl=64
8 bytes from icmp_seq=1 ttl=64
--- nas.lab.local ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss

#OSPFv3 for #Ipv4

A friend of mine told me something interesting

Ah, RIP to OSPFv2.
Now OSPFv3 supports IPv4 with the address families (IOS 15.0) on Cisco equipments

2015, the year of HTTP/2

From HAproxy website

January, 1st, 2015 : Year of a changing Web

I’m always surprized to see how very few people outside of the IETF HTTP working group are just aware of the fact that HTTP/2 is being worked on. At the time of writing, the draft is in the “Last Call” state which basically means that unless something critical is discovered, it will soon be adopted in its current form. Here “soon” means “around a few weeks”..

What will this change ? Probably not much at the beginning, but a lot soon. It will take some time before web site operators figure the performance benefits brought by HTTP/2, but the media will quickly boast its merits and the change can happen quickly, even if just to catch up with competiting early adopters. A number of sites already support SPDY for the same reasons right now but SPDY is constantly evolving and requires more attention from users who have to update often. By being a new standard, HTTP/2 will not require that level of care, and it will be perceived as the direct descendant of HTTP/1.1, which is why it will be more adopted than SPDY.

All major browsers already support HTTP/2, two of them (Firefox and Chrome) will only support it for HTTPS. Internet Explorer will drop SPDY support once HTTP/2 is adopted. That logically means that a number of web sites will decide to enable HTTPS in order to support HTTP/2 for the users of the two aforementionned browsers. HTTPS comes with an extra round trip at the beginning of the connection, but HTTP/2 saves a lot of them during the transfers so in the end if there are at least a few tens of objects to retrieve, it will still be an improvement.

But this will cause a new issue : migrating to HTTPS will mean that the caches that are operated in universities, enterprises, all mobile phone operators and many ISPs will not be used anymore. This will immediately have two impacts : the first one is that the traffic on the internet will increase. Alarmists used to say that the 40 Tbps trans-atlantic total capacity is almost saturated and hard to upgrade, we’ll see if that’s true. The second effect is that origin servers will get a significant traffic increase, which is good for ADC vendors as well as for CDNs which will get many new customers and increase their revenue. Sadly, in a number of poorly connected countries where client-side caches are critical to the survival of the Internet, CDNs will not be able to help and the situation will get even worse. That’s also the case for a number of mobile phone operators who can observe high cache hit ratios today.

What will very likely happen to address these situations is that ISPs and mobile phone operators will start to propose a faster Internet access to their customers in exchange for a root cert that they can happily install in their browser so that the operator can decipher SSL traffic on the fly and cache again. End users are already prepared to accept this because they don’t care at all about their privacy when it comes to whatever they do with their smartphone, otherwise they would always close their apps and type a password to access their emails. And the next logical step is that mobile phones sold by these operators will already have the root cert pre-installed in order to save a complex operation from the end user.

And that will lead to an interesting situation. First, SSL offloading solution vendors will happily see their sales increase. But the counter part is that the chain of trust of the SSL/TLS model will be definitely broken in that there will be no way for the end user to know if his data were safe or not. This chain is extremely fragile already and is regularly being abused, but now it could become the norm not to trust SSL anymore when rogue CAs becomes mandatory to access the net.

Fortunately, a few solutions are being worked on. On the HTTP working group they’re called “Trusted Proxies” or "GET https://", as a reference to what an HTTPS request through an explicit proxy could look like. They consist in letting the end user choose what can be deciphered and what cannot. That allows proxy operators to let some trusted sites pass through and to decipher/inspect/cache contents for all other ones. That’s how we could get a better Internet for everyone, with better caching and better privacy at the same time. Not sure it will happen by 2015 though, but we should do whatever we can for this to happen!

Stateless Autoconfiguration (EUI-64)

This article can also be found here.

Stateless Autoconfiguration (EUI-64)

IPv6 has changed the way we use private addressing.

In IPv4 you have to use one of the private IP addresses and apply it to the NIC before you can comunicate on your local network.

There is a little thing called APIPA (Automatic Private IP Addressing) in the Windows world that is used, curiously, when DHCP fails to do its job: it assigns and address in the network to the client that failed to contact the DHPC server.

But with the coming of IPv6 you can magically be sure that as soon as your NIC is up you’ll have a link-local address.

But what exactly is a link-local address?

Link-local address is an IPv6 address which is automatically created and assigned as soon as the NIC is connected and stays in the segment localized by that link.

It’s what I talk about in the title of this post.

You don’t have to do anything.

But how is possible?

Every NIC comes out of production with a tag you could say. This tag is the MAC address and is unique to the NIC (though it can be temporarily changed via OS, but that’s for another story).

It’s made of two separate part and is 48 bits in length.


The first part MM:MM:MM is the manufacturer, the second SS:SS:SS is the ID.

But why I told you this?

Because it’s used to do the magic behind  EUI-64.

We take the two parts of MAC and insert the hexadecimal number 0xFFFE


And then we do a little math and we flip the 7th bit so it’s a 1

After that we use the local network fe80::1.

Combine fe80::1 and the previous modified MAC and we get the IPv6 magic address!

Here is an example

MAC address:  0012.7feb.6b40

EUI-64  FE80::212:7FFF:FEEB:6B40

It was fun, no?

Till next time.