OK, I know why they changed the way checksums are done on IPv6 ICMPv6. It makes sense.

The change is that, just like UDP and TCP, the checksum includes a pseudo header (IPs, length and protocol).

But if you are daft enough to try and write code to map IPv4 to IPv6 it is not funny. Adjusting the checksum means allowing for adding and removing the pseudo header. Its complicated but doable.

That is, until, you try and map fragments! An IPv4 fragment (first fragment) needs the same changes but you don't know the total ICMP length from just the one fragment so you can't do the checksum adjust! Arrrrg!

Thankfully the fire-wall code collates all the fragments for a whole packet and processes as one, so it is able to just add up total ICMP size and make the adjustment.

So, now my 6/4 mapping code handles fragments and MTU cleanly.

The last bit I have to code is mapping ICMP errors so that you can traceroute through the 6/4 mapping. This is also important for basic things like no-route errors. That will be fun as I have to fake the quoted packet as well as the headers and do checksum adjusts. Of course if the error was for a fragmented ICMP I cannot actually adjust the checksum as I have no way to know original length, but that should be (a) rare, and (b) hopefully not checked by anything looking at the ICMP error anyway. Had hoped to do that today, but had a lie in.

So, soon, I'll have 6/4 mapping finished!!!

OK... Monday morning, all working!!!

[adrian@excalibur ~]$ ping -n -c1 news.bbc.co.uk
PING newswww.bbc.net.uk ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=58 time=4.07 ms

--- newswww.bbc.net.uk ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.076/4.076/4.076/0.000 ms
[adrian@excalibur ~]$ ping6 -n -c1 2001:8b0:6464::
PING 2001:8b0:6464:: 56 data bytes
64 bytes from 2001:8b0:6464::d43a:e28f: icmp_seq=0 ttl=56 time=6.24 ms

--- 2001:8b0:6464:: ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.245/6.245/6.245/0.000 ms, pipe 2
[adrian@excalibur ~]$ traceroute 2001:8b0:6464::
traceroute to 2001:8b0:6464:: (2001:8b0:6464::d43a:e28f), 30 hops max, 40 byte packets
1 boxless.ec.aaisp.net.uk (2001:8b0:0:31:ffff::) 0.522 ms 0.494 ms 0.481 ms
2 eclink.a.homeless.aaisp.net.uk (2001:8b0:0:31::51bb:1ffa) 1.479 ms 2.653 ms 3.827 ms
3 a.armless.thn.aaisp.net.uk (2001:8b0:0:53::5a9b:3506) 7.419 ms 8.636 ms 9.811 ms
4 doubtless.thn.aaisp.net.uk (:: 11.222 ms 12.413 ms 13.580 ms
5 a.armless.thn.aaisp.net.uk (:: 15.015 ms 16.693 ms *
6 rt-lonap-a.thdo.bbc.co.uk (:: 19.553 ms 4.434 ms 5.076 ms
7 :: (:: 5.909 ms 7.090 ms 8.473 ms
8 te12-1.hsw0.cwwtf.bbc.co.uk (:: 11.037 ms 11.841 ms 13.024 ms
9 nol-vip06.cwwtf.bbc.co.uk (:: 14.410 ms 15.580 ms 16.753 ms


  1. Congratulations!

    Next step.. disable ipv4 for everyone :p

  2. Yah! and it works.
    Mapped ICMP errors 4/6 and 6/4.

    I can traceroute through it, and traceroute even understands to do IPv4 reverse DNS, though mtr does not.

  3. What are your plans for the code? Are you planning to use it just within A&A, to sell it, or to release it as open source? I could imagine quite a lot of people wanting something like this, when RIPE start getting funny about issuing new IPv4 blocks!

    Sometime over the next year or so, I think IPv6 could become the new y2k bug. Suddenly people will realise that they need a strategy for dealing with it, and they will be looking for products that make the transition as straightforward as possible. That's one reason I've been wondering what strategies ISPs will follow. At the moment there is time to build products which would assist with the transition, but it's impossible without knowing the overall strategy ISPs will adopt.

  4. I have not done kernel level coding on linux yet, else I would consider open source of this. It needs to be kernel level really. The code is currently closed source and part of FireBrick FB6000 which we sell.

  5. I'm seriously considering buying a FB6000 or equivalent for our 10Mbit leased line, but not sure how it would handle the download QOS for VOIP.

  6. For 10M an FB105 would just about work, but the next generation FB2500 or FB2700 would be better as they are based on the FB6000 code. And yes, they will handle shaping for VoIP!

  7. Hello Love nice to see you back Moaning lol xxxxxx

  8. Odd that it traces :: rather than 2001:8b0:6464:0:666:616:5a9b:3508

  9. Ah, if I trace -I (ping) then it does.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.